A 




NAVAL POSTGRADUATE SCHOOL 

Monterey, California 




W &153 7 



THE DESIGN AND ANALYSIS OF A 
NETWORK INTERFACE FOR THE 
MULTI -LINGUAL DATABASE SYSTEM 



by 

demon R. Wortherly 

d • » 

December 1985 



Thesis Advisor: D. K. 

Approved for public release; distribution 



Hsiao 



is unlimited 



T239333 





I 






I 



I 





URirV CLASSIFICATION OF VhiS PAGE 



REPORT DOCUMENTATION PAGE 



REPORT SECURITY CLASSIFICATION 



1b. RESTRICTIVE MARKINGS 



SECURITY CLASSIFICATION AUTHORITY 



DECLASSIFICATION / DOWNGRADING SCHEDULE 



3. DISTRIBUTION /AVAILABILITY OF REPORT 

Approved for public release; 
distribution is unlimited 



>ERFORMING ORGANIZATION REPORT NUMBER(S) 



5. MONITORING ORGANIZATION REPORT NUMBER(S) 



NAME OF PERFORMING ORGANIZATION 

aval Postgraduate School 



6b. OFFICE SYMBOL 

s! 



(If applicable) 

>2 



7a. NAME OF MONITORING ORGANIZATION 

Naval Postgraduate School 



ADDRESS (City. State, and ZIP Code) 

3nterey, CA 93943-5100 



7b. ADDRESS (Ofy, State, and ZIP Code) 

Monterey, CA 93943-5100 



NAME OF FUNDING /SPONSORING 
ORGANIZATION 



8b. OFFICE SYMBOL 
(If applicable) 



9. PROCUREMENT INSTRUMENT IDENTIFICATION NUMBER 



ADDRESS (Ofy, State, and ZIP Code) 



10. SOURCE OF FUNDING NUMBERS 



PROGRAM 


PROJECT 


TASK 


WORK UNIT 


ELEMENT NO. 


NO 


NO. 


ACCESSION NO. 



TITLE (Include Security Classification) 

(E DESIGN AND ANALYSIS OF A NETWORK INTERFACE FOR THE MULTI - LINGUAL 
.TABASE SYSTEM (UNCLASSIFIED) 



PERSONAL AUTHOR(S) 

emon R. Northerly 



TYPE OF REPORT 

ster's Thesis 



13b TIME COVERED 
FROM TO 



14. DATE OF REPORT (Year, Month, Day) 

19 December 1985 



15 PAGE COUNT 

127 



UPPLEMENTARY NOTATION 



COSATI CODES 



[field 


GROUP 


SUB-GROUP 








1 







18. SUBJECT TERMS (Continue on reverse if necessery end identify by block number) 

Mult i- lingual Database System (MLDS) , Multi- 
backend Database System (MBDS) , Attribute-based 
Data Model. Attribute-based Data T.anaiiagp (Conti 



^ w 9 w— • ^ F vv w^ww V w w m ^ w w w w w V ^ m w j rw w w^w w j w 9 v / 

aditionally, the design and implementation of a conventional database 
^stem begins with the choice of a data model followed by the specification. 
J a model-based data language. Thus, the database system is restricted to 
p ingle data model and a specific data language. An alternative to this 
T^-ditional approach to database- system development is the mul t i - 1 ingual 
pabase system (MLDS) . This alternative approach affords the user the 
^iliLy to access and manage a large collection of databases, via several 
Ita models and their corresponding data languages, without the aforemen- 
oned restriction. 

thesis, we present a methodology for supporting network (CODASYL) 
jtabase management on the MLDS. Specifically, we design an interface 
|ich translates CODASYL-DML statements into ABDL requests. We describe 

control mechanisms, and the functions/procedures 
i .-essary to implement such a system ^ 



□ OTIC USERS 


21. ABSTRACT SECURITY CLASSIFICATION 

Unclassified 




22b. TELEPHONE (Include Area Code) 

408-646-2253 


22c. OFFICE SYMBOL 
5 7Hn 



*)ISTRIBUTI0N /AVAILABILITY OF ABSTRACT 
[lUNCLASSlFIED/UNLIMITED □ SAME AS RPT 



( NAME OF RESPONSIBLE INDIVIDUAL 

rof. David K. Hsiao 



t 



ORM 1473, 84 MAR 



83 APR edition may be used until exhausted. 
All other editions are obsolete. 



SECURITY CLASSIFICATION OF THIS PAGE 



1 



SeCUHITY CL ASSiriCATlON OF THIS (Whm* Data Kn«ara^> 



Block if 18 (Continued) 

(ABDL) , CODASYL Data Model, Network Database Translation 



Approved for Public Release, Distribution Unlimited, 



The Deslan and Analysis of a 
Metwortc Interface for the 
Multl-Llnoual Database System 



by 



Clemon R, Northerly 
Lieutenant, United states Navy 
B.s,, University of Texas, 1980 



Submitted In partial fulfillment of the 
requirements for the degree of 

MASTER OF SCIENCE IN COMPUTER SCIENCE 

from the 

NAVAL POSTGRADUATE SCHOOL 
December 1985 



ABSTRACT 



Traditionally, the design and implementation of a 
conventional database system begins with the choice of a 
data model followed by the specification of a raodel-based 
data language. Thus, the database system Is restricted to a 
single data model and a specific data language. An 
alternative to this traditional approach to database-system 
development Is the multi-lingual database system (MLOS), 
This alternative approach affords the user the ability to 
access and manage a large collection of databases, via 
several data models and their corresponding data languages# 
without the aforementioned restriction. 

In this thesis, we present a methodology for supporting 
network (CODASYL) database management on the MLDS, 
Specifically, we design an interface which translates 
CODASYL-DML statements Into ABDL requests, we describe the 
data structures, the control mechanisms, and the functions/ 
procedures necessary to Implement such a system. 
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I . IMXfiOOUCXlQU 



A, MOTIVATION 

During the past two decades, the design and 
Implementation of database systems has followed a rather 
predictable path. The sequence of events In the typical 
approach has been to decide on a data model, specify a 
model-based language, and ultimately, develop a system for 
controlling and executing the transactions written in the 
data language. This approach to database system development 
has resulted In an abundance of homogeneous database 
systems each of which restricts the user to a single data 
model and a specific model-based data manipulation language. 
Some examples of systems developed using this approach 
Include IBM's Information Management System (IMS) which 
supports only the hierarchical data model and Data Language 
I (DL/I), Sperry Unlvae's DMS-llOO wnlch supports just the 
network data model and the CODASYL Data Manipulation 
Language, and IBM's SOL/Oata System which supports solely 
the relational data model and the Structured English Query 
Language (SQL), 

An unconventional approach to the problem of database 
management system development, referred to as the Multi- 
lingual Database System (MLDS) (Ref, 1), eliminates the 
restrictions mentioned above. The MLDS would give the user 
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the ability to access and manage a large c 
databases, using several data models and their 
data languages. The design goal of the mlds pr 
development of a system that is acces 
hierarchical/DL/I Interface, a relational/SOL 
networ ic/CODASYL Interface, and an entl ty-relatl 
Interface, Such a system would function as If 
heterogeneous collection of database systems 
single model, single language system. 

Some of the advantages of a MLDS are the re 
database transactions developed on a convent 
economy and effectiveness of hardware upgrades 
upgrade just one system Instead of a number 
systems), and its ability to support a variety 
built around any of the well-known data models 
Is ample motivation for developing such a sy 
MLDS, 



ollectlon of 
corresponding 
oject Is tne 
slble via a 
Interface, a 
onshlp/Daplex 
it were a 
Instead of a 

useablllty of 
lonal system, 
(since we now 
of different 
of databases 
, Thus, there 
stem as the 



B, THE SYSTEM ORGANIZATION 

In order to realize the above capabilities, the mlds 
must be supported by an underlying database system that Is 
both fast, efficient, and effective. If these criterion are 
not met, then the Interfaces being developed for the MLDS 
may be rendered useless. Hence, it is Important that tne 
kernel data model and kernel data language (the underlying 
model and language for the system) be supported by a high- 
performance and hlgh-caoaclty database system. Currently, 
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the attribute-based data model and attribute-based data 
language are the underlying model and language of a system 
which Is referred to as the Mult 1-backend Database System 
(MBDS), In this section, we provide an overview of both tne 
MLOS and tne MBDS to enhance the readers understanding of 
the entire Multl-Llngual Database System, 

1, X&ft ttulti-Li&ouaX oatabiftft Sv&teo 

Figure 1 Illustrates the complete structure of the 
multl-llngual database system. The user Interacts with the 
system through the language Interface layer (LID, using a 
chosen user data model (UDM) to Issue transactions written 
In a corresponding model-based user data language (UDL), 
The LIL routes the user transactions to the kernel maoplng 
system (KMS), The Kms then performs one of two possible 
tasks. It either transforms a UDM-based database definition 
to an equivalent database definition based on the Kernel 



data model 


(KDM) ; 


or, when the 


user specifies that a 


UDL 


transaction 


is to 


be executed. 


It translates the 


UDL 


transaction 


Into 


an equivalent 


transaction in the kernel 



data language (KDL), 



The first task Is performed in the following way. 



The KMS forwards 


the 


KDM 


data 


definition 


to the kernel 


controller (KC), 


The 


KC 


then 


sends the 


KDM database 



definition to the kernel database system (KDS), When the 
KDS Is finished with processing the KDm database definition, 
it Informs the KC, The KC then notifies the user, via the 
LIL, that the database definition has been processed and 
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that the loading of the database records may begin. The 
second task is oerformed in a similar fashion. The KMS 
sends the transactions to the KC which in turn, sends the 
transactions to the KDS for execution. Once the execution 
Is comolete, the kds sends the results in the kdm form bac< 
to the KC, The KC routes the results to the Kernel 
formatting system (KFS), The KFS reformats the results from 
the KDM form to the UOM form. The KFs then displays toe 
results in the correct UDM form via the LIL, 




UDM : User Data Model 

UDL : User Data Language 

LIL : Language Interface Layer 

KMS : Kernel Mapping System 

KC ; Kernel Controller 

KFS : Kernel Formatting System 

KDM ; Kernel Data Model 

KDL : Kernel Data Language 

KDS : Kernel Database System 



Figure li The Multl-Llngual Database System (mlds). 



The four modules, 
collectively Known as 



LIL, KMS, KC, and KFS, are 
the lAoauaoa Four 
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Interfaces with similar modules are required for the four 
interfacing user models and languages (l.e,, relational/SQL, 
hierarchical/DL/i , network/COnASYL-DML, and entity" 
relatlonship/Daplex ) of the MLDS, 

2, ibft Muiti-aaciceQd Oataba&a 

The multi-backend database system (MBPS) was 
designed to overcome the performance problems and upgrade 
problems associated with the traditional approach to 
database system design. This goal was realized through the 
utilization of multiple backends connected in a parallel 
fashion. The backends have identical hardware, replicated 
software, and their own disk systems. In the multi-backend 
configuration, there is a backend controller, whlcn is 
responsible for supervising the execution of database 
transactions and for Interfacing with the hosts and users. 
The backends perform the database operations with the 
database stored on the disk system of the backends. The 
controller and backends are connected by a communications 
bus. Users access the system through either the hosts or 
the controller directly (see Figure 2), 

Performance gains are realized by Increasing the 
number of backends. If the size of the database and the 
size of the responses to the transactions remain constant, 
then MBDS produces a reciprocal decrease in the response 
times for the user transactions when the number of backends 
is Increased, On the other hand, if the number of backends 
is increased proportionally with the Increase in database 
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size and transection responses, then the MBDS produces 
Invariant response times for the same transactions. For a 
more detailed discussion of MBDS the reader Is referred to 
[Refs , 2 and 3 1 , 




Bus 



Store 1 





Store M 




Figure 2t The Multl-backend Database System (MBDS), 

In this thesis, we Investigate the design of a 
network (CODASYL) Interface for the MLdS, Banerjee tRef, 4J , 
provided an Initial design for such an interface, we are 
extending his work and adapting it to support the 
requirements of the MLDS, In particular, we present a 
specification for the kernel mapping system (KMS) that will 
be used In the network Interface, we also provide an 
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Implementation strateqy for the kernel controller (KC), 



The 



other two modules, the LIL and the KFS are nearly the same 
In structure as those already Implemented for the DL/I and 
SQL Interfaces, and thus, they will not be discussed In 
detail In this thesis. The reader Is referred to CRefs, 5 
and 61 for further details on the design of these modules. 

Throughout this thesis, we win make extensive use 
of the Suppl iers-and-Parts samole database used by Date 
[Ref, 71 for Illustration of our work. The data structure 
diagram for this network Is shown In Figure 3, There are 
supplier records (S), parts records (H), and shipments (SP) 
records. The sets of the database are suopliers-shlpments 
(S»SP) and parts-shlpments (P-SP), 



S 


p 


supoliers 1 


^mrnmmmmmmmmmmmmm 

1 parts 


V 


z 


m V w mm m 

( S-SP ) 


mmmmmm 

( P-SP ) 




Figure 3: Data Structure Diagram of the Sample 
Suppllers*and«Parts Database, 

In Chapter 2, we provide a description of both the 
network (CODASYL) data model and the attribute-based model, 
as well as, their associated data languages. In Chapter 3, 
a methodology for mapping a network (CODASYL) database Into 
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an attribute-based database Is presented. 



Chanter 4 Is 



oedlcated to 


explaining the data manipulation language 


translations. 


And, In Chapter 5, we Provide Implementation 


condlderatlons 


for both the KMS and the KC, finally, in 


Chapter 6 , we 
design • 


maice our conclusions about the proposed 
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II. XUS OAXA UQOSLS 



The choice of a kernel data model and a corresponding 
kernel data language is of vital Importance In developing a 
multi-lingual database system. The kernel data model and 
the kernel data language must be capable of supporting all 
the necessary data model transformations and data language 
translations reguired by the MLDS language interfaces. 

It Is our intention in this chapter to provide a summary 
description of the data models related to the network 
(CODASYL) Interface, namely the CODASYL data model and the 
attribute-based data model, A conceptual view of both 
models will be presented along with a brief discussion of 
the data manipulation languages associated with each model, 

A, THE CODASYL DATA MODEL 

In general, the network (CODASYL) data model Is based on 
the concept of directed graphs. The nodes of the graphs 
usually represent entity types which are described by 
records, while the arcs of the graphs correspond to 
relationship types that are represented as connections 
between records. The CODASYL (Conference on Data System 
Languages) data model Is referred to by Tslchritzls and 
Lochovsky (Ref, 8:pp, 119-1323 as the most comprehensive 
specification of a network data model that exists. Thus, the 
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reason for choosing the CODASYL iata model and Its data 
manipulation language for the network interface of the ^ILOS, 
1 • k CooccDtual q£ Lba Idodal 

CODASYL databases are networks of record types and 
set types, where records and sets are the entitles which 
describe the databases. A record type in a CODASYL database 
is defined in CRef, 4] as a collection of hierarchically 
related data item names or field names. These field names 
are specified in a schema declaration (template) for that 
record type, A ctcotd is any occurrence of a record type and 
has specific values assigned to the data items named in the 
schema declarations. This implies that a record type is 
simply a generic name for all of the records that are 
described by the same template. 

Set types in a CODASYL database indicate 

relationships between record types. They consist of a 

single record type called the ov&t£ record type, and one or 
more record types called the ffiaalias record types. Thus, a 
set type expresses explicit associations between different 
record types in the database. This characteristic makes it 
possible for a designer to model a large variety of real 
world database management problems Involving diverse record 
types. Of special Importance here is the fact that the 
owner record type of a set type Is prohibited from being a 
member of the same set type. 

Set types have occurrences just as record types do. 
Each occurrence of a set type has one occurrence of the 
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owner record type and zero or more occurrences of each of 



Its member record types. The prohibition here is that a 
record occurrence cannot be present In two different 
occurrences of the same set type. This qualification 
emphasizes the pairwise disjointness of set occurrences of a 
given set type. Figure 4 gives an example of a set 
occurrence for the set type S-SP of our sample database. 

As can be seen from the example^ the CODASYL data 
model makes the design of a database quite simple. However, 
keeping track of all of the reiationshlos can be 
considerably Involved, Thus, one of our primary concerns in 
the design of a CODASYL language Interface for the mlds Is 
to preserve these relationships without the complexity, 

s (an owner record occurrence) 
i S2 I Jones i 10 I Paris I 

(a set occurrence) 

(S-SP) 

(two member record occurrences) 

SP SP 

f... ........ ..t 

I S2 i Pi I 300 I i S2 i P2 I 400 | 

Figure 4i A CODASYL Set Occurrence, 

2, Xba LaoouAa* (CQQ&SXL-QttL) 

CODASYL-DMt. Is a procedural data language. The user 
of a CODASYL database writes his programs in a general 
purpose language that hosts the COPASyl-DML, in general. 
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most operations In a CODASYL database are carried out by 
"navlqatlng” through set occurrences. The starting point 
for this navigation Is usually the current record of the run 
unit. The cua uait Is the application program (transaction) 
being executed, A full explanation of currency will be 
provided later In the thesis* Other DmL operations can be 
based on the current record occurrence of a set type or 
record type, 

CODASYL-DML has several primary operations which 
support the primary database operations of retrieval, 
insertion, deletion, and modification (updating existing 
records). Different Implementations provide varying 
collections of these operations, but we will concentrate our 
discussion on the basic ones. 

The cornerstone of the CODASYL»Dml Is the [find 
statement. This statement Is used to establish the currency 
of the run unit, and optionally used to establish the 
currency of the set type and the record type. The general 
format of the FIND statement Is 

FIND record-selectlon-expressloh t ) , 

where the square bracicets contain optional expressions for 
the suppression of updates to the currency indicators. In 
other words, we may suppress the updating of the currency 
for a record type, a set type, or both. The record- 
selectlon-expresslon has several different forms each 
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designed to access a particular record in three different 
ways, either out-of-the-blue without reference to a 
previously accessed record; relative to a previously 
accessed record; or by repetition. The other dml statements 
are somewhat less extravagant* 

The GET Vstatement in COt)ASYl.»DML complements the 

w 

ETND statement. Once a record is found, the GET statement 
Places the record in the transaction's wording area for 
access by the transaction. There are two basic formats for 
the GET statement. They include GET record, type, which 
gives the transaction access to the entire record, and GET 
items IN record, type, which gives access to only requested 
data items in the record type. 

The jSTOR^ statement is used to Place a new record 
occurrence into the database. The programmer must build up 
an image of the record prior to the STORE request using 
assignment statements which are a part of the host language 
in which the CODASYL-DML is embedded. Once the record image 
has been created, then the proper set occurrence for the 
record must be selected by the database management system. 

The set occurrence in which the new record is stored 
is determined by the SET SELECTION clause specified in the 
schema definition for the object database. The three 
options available arei BY APPLICATION, which means that the 
application program (transaction) is responsible for 
selecting the correct occurrence; BY VALUE, which means the 
system selects the proper occurrence based on data item 
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values specific to the owner of the set occurrence desired; 
and, BY STRUCTURAL, which means that tne system selects an 
occurrence by locating the owner record with a specific item 
value equal to the value of that same item in tne record 
being stored. The restriction on tne last two options is 
that the data items being used must nave been specified with 
DUPLICATES NOT ALLOWED in the schema definition, A detailed 
discussion of syntax for the CODASYL-DmL is presented later 
in the thesis. 

If the user transaction desires to manually Insert 
records into the database, two requirements exist. First, 
the schema definition must Include the INSERTION is MANUAL 
clause in the set desciptlon for this particular member 
record. Then the connect statement is used, instead of the 
STORE statement, for insertion of the record into the 
database. The record to be Inserted is the current record 
of the run unit. The set occurrence in which the record is 
Inserted is determined in the same way as the STORE 
statement • 

There is also a statement in the CODASYL-Dml which 
performs the opposite operation, namely, the manual removal 
of a record occurrence from a set. The DISCONNECT statement 
performs this operation. It disconnects the current record 
of the run unit from the occurrence of the specified set 
that contains the record. The record occurrence still 
resides in the database, but it is no longer a member of the 
specified set. There Is a qualification Involved with this 
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statement, however. The record to be disconnected must have 
a RETENTION Clause of OPTIONAL In the memoer desciPtlon for 
the set type definition In the schema. 

In order to delete records from a cnoASYL database, 
the ERASE statement Is used. There are four basic options 
to this statement; however, two of them are very complex and 
marginally useful, so they will not be discussed in this 
thesis. The simplest of the two we will deal with is the 
ERASE without the ALL option. This statement causes the 
current record of the run unit to be deleted from the 
database If, and only If# It Is aot the owner of a non-empty 
set. If It is the owner of a non-empty set, the erase 
falls. 



The ERASE ALL option Is a little less useful 
according to Olle tRaf, 91, This statement causes the 
current record of the run unit to be deleted whether or not 
It Is the owner of a non-empty set# Additionally, this 
option causes each member record of the set to be deleted, 
and if they too are owners of non-empty sets, their members 
are deleted. This action continues all the way down the 
hierarchy. As one can see, an entire database could be 
destroyed if the user Is not careful when using this option. 
The final statement to be covered in this thesis is 
the MODIFY statement. It Is used to modify values of data 
Items In a record occurrence. This Includes modifying all 
data Items or any subset of the data Items In the record 
type. It may also be used to change the membership of a 
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record occurrence from one set occurrence to another, as 
long as, they are of the same set type. Thus, we have our 
basic wording set of DML statements. 

B. THE ATTRIBUTE-BASED DATA MODEL 

The attribute-based data model was originally described 
by Hsiao [Ref, 103, It is a very simple but powerful data 
model capable of representing many other data models without 
loss of information. It is this simplicity and universality 
that makes the attribute-based model the ideal choice as the 
kernel data model for the MLDS, and the attribute-based data 
language (ABDL) as the kernel language for the system, 

1, k CO&CAQtUAl UiftM Qt tUa UOdAl 

The attribute-based data model is based on the 
notions of attributes, and values for these attributes. An 
attribute and its associated value is therefore referred to 
as an attsibutft-iialu* oais or These attribute- 
value pairs are formed from a Cartesian product of the 
attribute names and the domains of the values for the 
attributes. Using this approach, any logical concept can be 
represented by the attribute-based model, 

A £ftCo£d f in the attribute-based model represents a 
logical concept. In order to specify the concept 
thoroughly, keywords must be formed, A record then, is 
simply a concatenation of the resultant keywords, such that 
no two keywords in the record have the same attribute. 
Additionally, the model allows for the inclusion of textual 
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In the form of a, 



information, called the ceco£d £odv # 
possibly empty, string of characters describing the record 
or concept. The record body is not used for search 
purposes. Figure 5 gives the format of an attribute-based 
record, 

COttrlbutel , valuel>, ,,, , 

<attrlbuten, valuen>, 

{ text }) 

Figure 5i An Attribute-Based Record 

The angled brackets, <,>, are used to enclose a keyword 
where the attribute is first followed by a comma and then 
the value of the attribute. The record body is then set 
apart by curly brackets, <,>, The record itself is 
identified by enclosure within parentheses. As can be seen 
from the above, this is quite a simple way of representing 
information. 

In order to access the database, the attribute-based 
model employs an entity called predicates, A keyword 
predicate, or simply , Is a triple of the form 

(attribute, relational operator, value). These predicates 
are then combined in disjunctive normal form to produce a 
ouacv of the database, in order to satisfy a predicate, the 
attribute of a keyword in a record must be identical to the 
attribute in the predicate. Also, the relation specified by 
the relational operator of the predicate must hold between 
the value of the predicate, and the value of the keyword, A 
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record satisfies a query If all predicates of the query are 



satisfied by certain Keywords of the record, A query of two 
predicates 



(TYFE = S) and (SNO s S4) 

would be satisfied by any record of TYPE S (supplier type) 
whose SNO (supplier number) Is S4, and it would have the 
form, 

(Kattributel,vauel^f ,KTYPE,s^f § 

<SN0,S4>, ,,, ,<attrlbuten,valuen>, <text> ) , 

2. x&a 4tt£i.butA-&afttci Qata Laoouaoa (id&b) 

The ABDL as defined by Banerjee, Hsiao, and Kerr 
[Ref, 11] was originally developed for use with the Database 
Computer (DBC), This language Is the Kernel language used 
in the MLDS, The ABDL supports the five primary database 
operations, INSERT, DELETE, UPDATE, RETRIEVE, and RETRIEVE** 
COMMON, Those of use to us in this portion of the mlos worK 
nowever, are INSERT, DELETE, UPDATE, and RETRIEVE, A user 
of this language issues either a request or a transaction, 
A caauatt in the ABDL consists of a primary operation with a 
qualification. The oualiticatlfifi specifies the portion of 
the database that is to be operated on. When two or more 
requests are grouped together and executed sequentially, we 
have a t&a&iae&io& in the ABDL, There are four types of 
requests, corresponding to the four primary database 
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operations listed above. 



They are referred to by the 



same names. 

Records are Inserted Into the database with an 
INSERT request. The qualification for this request Is a 
list of iceywords and a record body. Records are removed 
from the database by a DELETE request. The qualification 
for this request is a query, 

When records In the database are to be modified, the 
UPDATE request Is utilized. There are two parts to the 
qualification for this request. They are the query and 
modifier. The query specifies the records to be modified 
while the modifier specifies how tne records are to be 
modified. 

The final request to be mentioned here is the 
RETRIEVE request. As Its name Implies, It retrieves records 
from the database. The qualification tor this request 
consists of a query, a target-list# and an optional by- 
clause, The query specifies the records to be retrieved. 
The target-list contains the output attributes whose values 
are required by the request, or it may contain an aggregate 
operation, i,e,, AVG, COUNT, SUM, min, max, on one or more 
output attribute values. The by-clause Is optional and Is 
used to group records when an aggregate operation Is 
specified. 

As indicated, ABDL consists of some very simple 
database operations. These operations, nevertheless, are 
capable of supporting complex and comprehensive 
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transactions. Thus, abdl meets the requirement of capturinq 
all of the primary operations of a database system, and is 
quite useful for our purposes. Figure 6 shows examples of 
the four primary ABDL requests, 

INSERTC<TYPE,SP>,<SN0,S2>,<PN0,Pl>,<QTy ,300>, (sample)) 
DELFTEC (TYPE = S) and (SNO c S4)) 

UPDATECCTYPE s SP) and (PNO s P1))(0TY * OTY f 100) 
RETRIEVEC (TYPE = P) and (PNAME a Nut)) 

Fiqure 6t Sample ABDL Requests, 
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III. UASeiUC USXMQSi^ (CQQASXL) OAZA IQ &ZX£l&UZe-a&SEC QAXA 



Using a modification of a procedure originally outlined 
by Banerjee CRef, 4], the transformation of network data 
into attribute-based data becomes a relatively simple task. 
The data must be transformed into records wnich consist of a 
set of variable-length attribute-value pairs and a record 
body. The attribute-value pairs may represent the type, 
quantity, or characteristic of the value, and the record 
body is as described in the previous chapter. Additionally, 
all attributes in the attribute-based records are distinct, 
for logical reasons. 

The key aspect of the mapping ^r^oces s is the retention 
of the CODASYL notions of records and sets (the linkages 
among records ), we emphasize that the CODASYL notions of 
records and sets are qq£ the same as__^he attribute-based 
notions ^ records and sets,_ Thus, the mapping algorithm 
presented herein uses attribute-based constructs Cor 
notions) to implement the CODASYL notions. In the following 
sections, we present the various entities which must be 
mapped, their corresponding attribute-based equivalent, and 
an example of the mapping process using our sample database. 
It Should be clear after this description, that the COD AS YL 
notions of records and jth^r ^relationships are ln<^ed 
preserved in the attribute-based system. 
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A. THE representation OF A CODASYL RECORD 





A CODASYL 


record type Is structu 


red as a hierarchical 


conf 


iguratlon 


of data items such as 


depicted in Figure 7Ca), 


wher 


e R1 is t 


he record name, and A, 


8 , C , D , 


E, and F 


XI 


esent da 


ta Item names. Figure 


7(b) snows an 


occurrence 


of r 


ecord Rl, 


Notice that only the 


values of the 


data items 


are 


present 


in the CODASYL record. 


In the attribute-based 


syst 


em# both 


the data-1 tern-name and 


its value are 


stored in 


the 


record. 










Record Rl 




Record Rl 
















01 A 




1 aOl.value 


1 




01 B 




1 bOl.value 


1 




02 


C 


1 c02»value 


1 




02 


D 


1 d02»value 


1 






03 E 


1 e03«value 


1 




02 


A 


1 a02»value 


1 




01 F 




1 fOl.velue 


1 














(a) 




(b) 






Figure 7: 


Hierarchical structure 


Of a CODASYL 


Record, 


Thus 


, In order to capture the CODASYL information 


, Jceywords 


must 


be created for each of the elementary 


data items 



Included In the CODASYL record. These data-item iceywords 
should be o£ the form 

< data.ltero..name^data«.ltem«iValue > 

where the data-item-name Is qualified by data-ltem-names at 
a higher level If It Is not unique. Figure 8 shows the data 
Item representation for the CODASYL record of Figure 7, 
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(,,,,< A,a«value >,< B,b«value >, 

< C,c. value >,< 0, devalue >, 

< E,e. value >,< B, A ,b.a.veiue >, 

^ Pf£sValue 



Figure 8j Attribute-Based Hepresentat ion of 



The dots at the beginning of the record and the dots at the 
end of the record indicate that there are additional 
keywords generated for the record in order to preserve the 
CODASYL record information. These additional keywords are 
explained as follows, 

Each record occurrence in a CODASYL database must also 
belong to a particular type. This implies that a keyword 
indicating record type must also be included in the 
attribute-based record. Its format is 



where TYPE is a literal. 

Finally, each record occurrence of a database 
has a database key (or address) generated for_itt_ Thus, 
there is a requirement for representation of this value as 
well in the attribute-based record. The following form is 
used for this keyword, where dbkey Is a literal. 



CODASYL Data Items 



< TYPE,record«type > 
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So, In representing record information, we have the need 
for three mandatory keyword types, namely, date.ltem,name , 
with or without qualification, TYPE, and D6KEY, 

B, THE REPRESENTATION OF CODASYL SETS 

In order for the attribute-based record to be complete. 
It must also Include information related to COOASYL set 
membership, and set ordering. Since occurrences of set 
types are pairwise disjoint, then each member record 
occurrence belonging to a set occurrence Is also identified 
by Its owner record occurrence. This means that we can 

express set membership by Inclusion of the keyword 

< MEMBER, set*type,owner,,database«key > 

for each set occurrence In which the record Is a member. 

Finally, the logical position of a record occurrence 
within a sjt_occurrence Is often usef^. Thus, ord ering of 
member record occurrences within a set occurrence Is 
expressed by Inclusion of the keyword 

< POSITION, 8et.type,sequence»number > 

In the attribute-based record for each set In which th^e 
record Ij a m^ber recor^. 

Therefore, In representing set Information, we have t he 
need for two keyword types, those representing member 
records, and those representing member-record posit ions 
within sets. 
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A COMPLETE DATA-MAPPING EXAMPLE 



As previously mentioned, by utilizing tne above 
transformation scheme, we can take an existing CODASYL 
database and transform It into an attribute-based database 
without any loss of Information related to tne CODASYL 
records and sets (l,e,, record relationships), the 
transformation should therefore result in records of the 
form shown in Figure 9, 



(< TYPE, record.type >,< DBKEY,database.key >, 

< data.ltem.namel , data^ltem.valuel ># 

t 

< data.ltem.namen,data«ltem.valuen >, 

< MEMBER, set^typel ,owner«database«keyl >, 

t 

• 

< MEMBER, set«typep,owner«database.keyp >, 

< POSITION , set.typel , sequence-number >, 

• 

f 

f 

< POSITION, set-typep, sequence-number > 

{ textual Information >) 

Figure 9: An Example of a Transformed 
CODASYL Record, 
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SCHEMA NAME IS SUPPLIERS.AND.PARTS , 

RECORD NAME IS S; 

DUPLICATES ARE NOT ALLOWED FOR SNO, 

SNO ; TYPE IS CHARACTER 5, 

SNAME ; TYPE IS CHARACTER 20, 

STATUS ; TYPE IS FIXED 20, 

CITY ; type IS CHARACTER 15, 

RECORD NAME IS P; 

DUPLICATES ARE NOT ALLO»*ED FOR pNO, 

PNO ; TYPE IS CHARACTER 6, 

PNAME ; TYPE IS CHARACTER 20, 

COLOR ; TYPE IS CHARACTER 6, 

WEIGHT ; TYPE IS FIXED 4, 

CITY ; TYPE IS CHARACTER 15, 

RECORD NAME IS SP; 

DUPLICATES ARE NOT ALLOWED FOR SNO, PNO, 
SNO ; TYPE IS CHARACTER 5, 

PNO ; TYPE IS CHARACTER 6, 

QTY ; TYPE IS FIXED 5, 

SET NAME IS S«SP; 

OWNER IS S; 

ORDER IS SORTED BY DEFINED KEYS 
DUPLICATES ARE NOT ALLOWED, 

MEMBER IS SP; 

INSERTION IS AUTOMATIC 
RETENTION IS FIXED; 

KEY IS ASCENDING PNO IN SP; 

SET SELECTION IS RY VALUE OF SNO IN S, 

SET NAME IS P«SP; 

OWNER IS P; 

ORDER IS SORTED BY DEFINED KEYS 
DUPLICATES ARE NOT ALLOWED, 

MEMBER IS SP; 

INSERTION IS AUTOMATIC 
RETENTION IS FIXED; 

KEY IS ASCENDING SNO IN SP; 

SET SELECTION IS BY VALUE OF PNO IN P, 

Figure 10* Schema for the Suppliers-and-Parts 
Database, 



In order to demonstrate the transformation process 
further. Figure 10 above provides the schema definition for 
our sample Suppllers-and-Parts database. Using this schema 
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definition, the CODASYL record occurrences of Figure 11 are 
transformed into the attr Ihute-based records of Figure 12, 



S 

I S2 I Jones I 10 I Paris I 
P 

fmmmmmmmmmmmmmmmmmmmmmmmmmmmrnmm^ 

I PI I Nut I Red I 12 I London I 
SP 

I S2 I PI I 300 I 

Figure 11: sample Record Occurrences from the 
Suppllers-and-Parts Database, 



(<TyPE,S>,<DBKEy, i>,^ 

<SN0,S2>,<SNAMe, J ones >, 

<STATUS, 10>,<CITy,Parls>, 

< Sample supplier record >) 

(<TyPE,P>,<DBKEy ,2>T^ 
<PNO,Pl>,<'PNAME,Nut>, 

<C0L0R,Red>,< WEIGHT, 12>, 

<CITY ,London>, 

{ Sample parts record >) 

(<TyPE,SP>,cDBi^y,3>,"^ 
<SN0,S2>,<PN0,P1>, 

<OTy-,300>, 

/ <MEMBER,S.SP, 1>, 

<MEMBER,P.SP,2>, 

<P0SITI0N,S.SP,1>, 

<P0SITI0N,P.SP,J>,. 

< Sample SP record where the record 
belongs to two different sets )) 



V 



Figure 12: Attribute-Based Equivalent of Record 
Occurrences In Figure li. 
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IV. KAESIUfi COQ&SXL-OtfL SZ4ZCiiCUXS ZQ 4aQb &CQUZSZS 



Having demonstrated how network databases can be 

successfully transformed Into attribute-based databases# we 
are now ready to examine the mapping of network data 
manipulation statements Into ABDL requests. As mentioned in 
Chapter 2 , the CODASYL data manipulation language will be 

used for the ML.DS network Interface, It should be noted 

here though, that only a subset of all the available DML 
statements will be used In the MLt)S network Interface, 
Specifically, the following CODA5YL statements will be 

Incorporated in this stage of the project: FIND, GET, STORE, 
CONNECT, DISCONNECT, ERASE, and MODIFY, Of these, only the 
useful formats were considered for the mlds. It should be 
further noted that the syntax for these various statements 
was derived from the syntax presented by Date, Olle, and the 
original CODASYL report [Refs, 7, 9, and 12]# respectively. 
In this section we discuss each of the above statements 
and their associated mapping process. Prior to describing 
the mapping, however, we first explain the notion of 
currency In a CODASYL database, and Introduce the data 
structures that are necessary to carry out the mapping 
process. The Appendix, the KMS (Kernel Mapping System) 
specification, gives a detailed look at the mapping process 
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and the specific algorithms applied to accomplish the 
language translations, 

A, THE NOTION OF CURRENCY 

In general, the above data manipulation statements can 
be grouped into two categories, data retrieval statements 
and data updating statements. However, the common thread 
between the two groups, as well as, tne individual 
functionality of each statement, depends quite heavily on 
the notion of cuxLCeacv among the records and sets of the 
CODASYL database. 

The concept of currency In a CODAsYL database can be 
compared to the well known concept of current position in a 
file. The idea here is that for each application program 
being run on the system, a table of “currency indicators" is 
maintained. In general, the currency indicator is an object 
whose value is a dAtabasft It serves as a “cursor" 
which points to either a record or a set under consideration 
by the application program. Database keys are values 
generated by the database management system that uniquely 
identify each individual record in tne database. 

The currency indicator table for a given application 
program (or run unit) identifies the record occurrence “most 
recently accessed" by the run unit for each of the 
following: each type of record, each type of set, “any type" 
of record, and each type of realm (Realm is a CODASYL 
concept that will not be considered in this thesis,) "Any 
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type" of record refers to the most recently accessed record 
occurrence, no matter what Its type is. This record is 
appropriately called, the cu£caot Qt t&a £U& uait , and is 
the most Important currency of all. Additionally, the 
cu££ao& o£ tba set taut may be either an owner record or a 
member record, whichever was accessed most recently, 

B, DATA STRUCTURES NECESSARY FOR ACCURATE TRANSLATION 

1, laa Cu££aacv Iod4.cato£ Zabla (CIX) 

A currency indicator table (CIT) Is created for each 
application program that is run using the MLDS network 
Interface, These tables are dynamic in nature. They are 
instantiated upon the first call to the database system, and 
are updated as subseouent COOASYL*DML calls are made to the 
database system, 

CIT 

RUN.UNIT 

record.type 

database.Key 

record.typed) 

database.Key 

set.type(l) 

boolean (Is record an owner record) 

record. type 

database.Key 

member. record.type 

owner. record. type 

owner. database.Key 

Figure 13t Information Contained In the CIT, 

The CIT contains an entry for the current of run 
unit, the current of record.type for each record.type In the 
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database, and the current of set«type for each set.type in 
the database. Each entry in the CIT should contain at least 
the information shown in Fiaure 13 as sugqested by Meyer 
[Ref. 133. 

2. Xba Saoue&t autXas (£&) 

When mapping the CODASYL-DML statements to ABOL 
requests, there are one»to*many correspondences between tne 
two types of statements. Thus, for each CODASYL-DML 
statement, several ABOL requests may have to be generated to 
assemble the necessary information for accurate execution of 
the translated CODASYL-DML statement* In other words, a 
series of ABDL requests may be generated for each CODASYL- 
DML statement. Some of the requests are initially 
Incomplete, however, and require information returned by 
previous RETRIEVE requests which are a part of that 
statement's translation. This Implies the need for storage 
of intermediate Information for the requests. 

The request buffer (RB) acts as that storage 
mechanism for information returned by what we term, 
auxiliary retrieve requests (ARR'S), There must be one RB 
for each RETRIEVE request Issued, The exact role that each 
buffer Plays Is explained In the next section of this 
chapter. In general though, upon successful execution of an 
ARR, all record occurrences satisfying the request are 
maintained in the buffer. This information Is then used for 
subsequent request execution. 
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C, MAPPING THE FIND STATEMENTS TO THE ABDL RETRIEVES 
The general format of the CODASYL FIND statement Is 

FIND record.selectlon-expresslon [ ], 

while the general format of the ABDL retrieve Is 

RETRIEVE Query Target-list t by Attributes 3, 

As previously stated, there are several formats for the FIND 
statement, each with a different functionality. Some of 
these, however, are thought to be considerably more useful 
than others, so we only concern ourselves with the ones of 

most value In the MLDS, Before proceeding, the reader 

should note that In CODASYL statements, upper-case notation 
represents literals, lower-case represents user supplied 
variable names, and square bracKets Indicate optional 
clauses. We now examine the mapping process for each of the 
CODASYL statements to be included In the MLDS networtc 
Interface, 

1, SXfitQ kUl stataoft&t 

The FIND ANY statement tells the database system to 
locate any record of type, record.typel , whose values for 
iteml through Itemn match those in that record's template in 

the user wor)c area. The syntax for the FIND any is: 

FIND ANY record. typel USING Iteml, ,,, , Itemn 
IN record. typel , 

To perform the mapping of this statement, the kernel mapping 
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system (KMS) must first substitute the word RETRIEVE for the 
words FIND ANY, Then the KMS must form a predicate, (TYPE = 
record-typel ) , for Inclusloh In the final query. The next 
step In the process requires the kms to determine the values 
that the search Is to be based on. These values are found 
In record.typel 's record template. 

After acquiring these values, the kms then forms 
additional predicates for the data Items specified In the 
original statement, and includes these predicates in the 
query, since all of the necessary information is available 
to the KMS for this particular CODASYL statement, there is 
no need for an auxllllary retrieve request (ARR), However, 
an R6 Is needed to store the retrieved data once the request 
has been executed, 

with the query now formed, the kms creates a 
target-list to complete the RETRIEVE request. The target- 
list consists of all attributes of the requested record. 
Thus, the translated CODASYL-Dml statement Is: 

RETRIEVE (( TYPE * record.typel ) and 
Clteml s user.valuel) and 

: and 

(Itemn e user.valuen) ) 

( all attributes ) C by DBKEY ], 

This request is then passed to the KC of the interface for 
execution. An example utilizing our sample database will 
help to illustrate the mechanics of the mapping process. 
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The requirement is to find any Supplier 
where that supplier's city Is 'Cleveland', 
procedure is* 



record, S, 
The CODASYL 



MOVE 'Cleveland' TO CITY in s 
FIND ANY S USING CITY IN S 



(Notej The MOVE statement Is an assignment statement found 
In the host COBOL language,) The KMS would respond to this 
series of code by performing the following actions: 



step II 'Cleveland' is placed in the S template for the 
attribute CITY, 

Step 2: A RETRIEVE request is formed as such: 

RETRIEVE ((TYPE e S) and 

(CITY = 'Cleveland')) 

(SNO, SNAME, STATUS, CITY) 
by DBKEY 



Step 3: The KMS passes the request to the KC for 
execution. 

This operation results in having all s records satisfying 
the query ((TYPE s s) and (CITY = 'Cleveland')) placed in 
the request buffer and sorted according to the value of the 
database Keys, Figure 14 shows the contents of Bufl after 
the RETRIEVE is executed. 



I I 
I <S6, Mathews, 25, Cleveland> I 
I <58 , Jones , 30 ,Cleveland> I 
I I 

tmmmmmmmmmmmmmmmmmmmmmmmmmmmmi. 



Figure 14: Contents of bufl After RETRIEVE, 
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Upon Issuance of a GET statement by tbe user, the first 
record In the RB is returned, provided tne RETRIEVE has been 
successful • 

2 , I12A £l&iO cusseux StatAOAfit 

The FI^D CURRENT statement is a rather simple one in 
that no direct mapping to an ABOL request is necessary# 
This statement is used to change the current of run unit 
indicator from its present value to the value of the 
database Key of the current record of set.typel. Thus, the 
interface has the responsibility of updating the current of 
run unit indicator (l.e., CIT#RUN. UNIT, type <«• record, typel 
and CIT.RUN.UNIT.dbkey <— dbkey of current of set,typel). 
The syntax for this statement 1st 

FIND CURRENT record, typel WITHIN set,typei 

As an example of this process, suppose we desire to 
start a search at the current SP occurrence in set, type S- 
SP# The CODASYL Statement would bei 

FIND CURRENT SP WITHIN S«SP 

After encountering this statement, the KMS passes the update 
information on to the KC for execution. The KC then updates 
the currency indicators to reflect tne chanoes. The current 
of run unit becomes the current SP record occurrence of the 
current S-SP set occurrence# 
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3. Zbe exl^Q QUSLXCAXE IXXtiXll Statamtot 

The FIND DUPLICATE statetpent Is useri for sequential 
access within a particular set occurrence, it locates the 
first record.typel record within the current set.tyoel 
occurrence whose values for Iteml through Itemn match those 
of the current record of set^typel. The syntax used for 
this statement Isi 

find duplicate within set«typel USING 
Iteml, ,,, , Itemn IN record„typel 



The mapping process for this request assumes that 
the records being requested are already in an RB, 
Therefore, no RETRIEVE request Is generated for this 
statement. Instead, the KMS forwards the set type, record 
type, and the data Item nameCs), on which the search Is 
based, to the KC. The KC then takes this Information, and 
locates the RB containing the set. It then compares the 
specified data Item values for the current record of the set 
type to each of the other member records until the first 
duplicate record within the set Is found. This record Is 
made available for return to the user. The CIT Is then 
updated to reflect the new currency status. This approach 
Is advantageous, In that, all of the records for a 
particular set occurrence are already available In an RB, 
eliminating the need for further accesses to the database In 
the event of subsequent requests for duplicate records, such 
as would be the case In a loop. 
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The following example illustrates the maoplng 
process: Find the next shipment record tor supoller SI in 
which the quantity snipped Is 100, A possible COOASYL 
procedure for accomplishing this consists of the following 
statements : 



MOVE 'SI' TO SNO IN S 
FIND ANY S USING SNO IN S 
MOVE 100 TO OTY IN SP 

FIND SP WITHIN S-SP CURRENT USING OTY IN SP 
FIND DUPLICATE WITHIN S-SP USING QTY TN SP 



The effect of the first four statements is to locate the 
first SP occurrence for supplier Si that has a QXY of 100, 
The next statement finds the next SP record In the S-SP set 
with the same OTY, namely, 100, 

The interface would respond to the FIND DUPLICATE 
request as follows: 



Step 1: Execution of the first four statements produces 
the results in the RB of Figure 15. 



Step 2: The KC then gets the value of the data item, 
OXY, by going to the RB and finding the current 
record of the S-SP set using the record.type and 
set. type Information given. 



Step 3: The KC now locates the next record in the set with 
OTY * 100 and maices it ready for return to the 
user. 
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I I 
I <S1,P5,100> I 
I <Sl,p6,100> I 
I <Sl,P8,100> I 
I <S1,P10,100> I 
I I 

Figure I5i Contents of bu£l, 

4. Xbe CIUQ EIB&I Statefift&x 

The FIND FIRST Statement locates the first member 
record of a set occurrence. This statement has several 
other forms: FIND LAST, FIND NEXT, and FIND PRIOR, Since 
they are all mapped in exactly the same way, we only 
describe the mapping process for the Find FIRST, The syntax 
for the FIND FIRST is: 

FIND FIRST record-typel WITHIN set.typel 

Upon encountering the FIND FIRST, the KMS must 
ensure that record.typel is a member record type of 
set.typel. This is necessary, since this particular FIND is 
based on the currency Indicators, and the current of 
set.typel may be an owner record, as noted earlier when 
discussing currency of set types. Assuming that the current 
record of set.typel is a member record, the KMS then forms a 
RETRIEVE request that will retrieve every member record of 
the current set.typel occurrence into its RB, The Interface 
would then only have to return the first record in the set 
in order to satisfy the request. If the statement had been 
FIND LAST, the last record in the set would be returned. 
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The response would be similar for the FIND next and 



FIND PRIOR statements. Assuming that the set occurrence has 
already been retrieved into an RB, the interface would 
simply locate the current record of set.typel in the HB and 
return the record after It In the case of FIND next, or the 
record before, it In the case of the find PRIOR, The fact 
that all of the member records of the set occurrence are 
already In an RB, eliminates the need for additional 
database accesses. Thus, the only ABDL request that need oe 
formed is this* 



RETRIEVE ((TYPE a record.typel) and 

(MEMBER, set.typel a owner*db>cey,8et«*typel ) ) 
(all attributes) tby DBKEy) 



As an example, consider the following requesti Find 
all the part numbers (PNO^s) for parts supplied by supplier 
S4, A possible CODASYL procedure to accomplish this would 
be: 



MOVE '54^ TO SNO IN S 
FIND ANY S USING SNO IN S 
MOVE 'NO^ TO EOF 
FIND FIRST SP WITHIN S-SP 
PERFORM UNTIL EOF a 'YES^ 

GET SP 

(add PNO IN SP to result list) 
FIND NEXT SP WITHIN S-SP 
END.PERFORM 



The statements of concern here are the find first 
and the FIND NEXT, The reader need only be aware that in 
CODASYL only one record at a time Is made available to the 
user. Thus, the need for tne perform loop# 



49 



In response to the above sequence of statements, the 



Interface would perform these steps! 



Step 1: The kms of the interface would form a retrieve 
request to get all members of the S-SP set owned 
by supplier S4, Since each record has a predicate 
which Identifies them as members of a particular 
set occurrence, the task Is fairly easy. The re- 
quest Is: 

RETRIEVE ((TYPE » SP) and 

(MEMBER, S-SP s dbkey of S4)) 

(SNO,PNO,OTY) [by PNO] . 



The results of executing this request are shown In Figure 
16, We can see that every member record of the set has been 
fetched from the database and Is available for return to the 
user. The FIND FIRST causes the first record to be returned 
to the user. 

Step 2: Since the COdasyl procedure has a find next 
statement, the same RB is used. In other words, 
the KC does not need to execute a new retrieve re- 
quest, It merely makes available the next record 
In the RB until all records have been returned to 
the user as per the loop. 

Since we are only looking for PNO values, the interim user 
code would specify the attribute to be returned and the 
Interface would respond accordingly. 



I I 
I <S4,P2,200> I 
I <S4,P4,300> I 
I <S4,P4,400> I 
I I 

Figure 16: Contents of Bufl After RETRIEVE, 
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5. iba ex^o QklUKa StdX«D«ot 

The FIND OWNER Statement causes the owner of the 
current of set.type occurrence to be returned to the user. 
The syntax for this statement is: 

FIND OWNER WITHIN set.typel 

The mapping of this statement is relatively straightforward. 
The KMS must simply form a RETRIEVE request based on 
information available in the CIT, Tne KMS examines the CIT 
entry for set«typel and extracts the owner's type and 
database key value directly from the table# It is then an 
easy task to form the request: 

RETRIEVE ((TYPE a. owner Of Set.typel) and 

(DBKEY a Owner dbkey of set.typel)) 

(ail attributes) 

As an example# suppose we want to know the STATUS of 
the supplier for part number P6, Let us assume that 
previous statements have set up the current S-SP set 
occurrence to be S2/P6/20, The CODASYL statement is: 

FIND OWNER WITHIN S-SP, 

In response to this request, the Interface takes the 
following action: 

Step 1: The KHS forms the request: 

RETRIEVE ((TYPE s S) and 

(DBKEY a dbkey of S2)) 

(SNO,SMAME, STATUS, CITY) 
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step 2: Trie kc would cause the execution of the above 
request, resulting In an RB containing one record, 
namely, the S2 record. 

Based on the Interim user code, the STATUS value is returned 
to the user from the RB by the Interface, 

6 , Xt^a £IU0 UXZtiltf CUEfiEUZ Stataffiaot 

This statement causes the first record within the 



current occurrence 


of set.typel whose 


values 


for 1 


teml 


through itemn match 


those in the uses 


UO£l( 


a£*a 


for 


record.typel. The 


following syntax is 


used 


for 


this 



statement, 

FIND record. typel WITHIN set.typel CURRENT 
USING Itemi, ,,, ,ltemn IN record. typel 

This statement is similar to the FIND DUPLICATE 
except that the search values are obtained from the user 
vice the current record of set type. Thus, only a single 
RETRIEVE request is needed. That request taxes the formj 

RETRIEVE (CTPYE = record.typel) and 

(MEMBER, set.typel a dbxey of owner set.typel) 
and (itemi = user valuel) 

and , • • 

and (Itemn a user valuen)) 

(all attributes) (by DBKeY] 

This request is then passed to the KC for execution. If 
there is more than one record satisfying this query, the RB 
for the request contains them all. However, only the first 
record encountered is returned to the user. 

To Illustrate the process of this mapping, we return 
to a previous exampiei FIND the first shipment for supplier 
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SI In which the quantity Is 100, Uslno the first four 
statements from the example In section C,3 we have, 

MOVE SI TO SMO IN S 
FIND AMV S USING SNO IN S 
MOVE 100 TO QTY IN SP 
FIND SP WITHIN S-SP 

CURRENT USING OTY IN SP, 

In order to carry out this request, the following steps are 
taken by the Interface: 

Step 1: The KMS forms the request: 

RETRIEVE ((TYPE s SP) 

and (MEMBER, S-SP « dbkey of SI) 
and (OTY s 100)) 

(SNO,PNO,QTY) [by DBKEY] 

Step 2: The KC executes the above request and causes the 
first record In the RB to be made available to the 
user, 

D, MAPPING THE CODASYL GET STATEMENTS 

The GET statements In the CODASYL-DML can be considered 
as data retrieval statements just as the FIND statements 
are, except that the GET request can only access records 
that have been previously Identified by a find statement. 
It is the statement that actually gives the user access to 
the Individual records. There are three options available 
with the GET statement, and we examine each In turn. In 
developing these mappings, we decided not to directly map 
the GET statements to ABDL RETRIEVE's, but to simply Issue 
Instructions to the KC for handling them. 
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1 . 



XbA G£X AQd C£X cftco£d.tv&« Stataoeats 



The GET statement, without the specif Icet ion of a 
particular record type, causes the entire current record of 
run unit, that Is, every data field In the record, to be 
returned to the user via the User Wortc Area (UWA), In tne 
MLDS network interface, recog niton of this statment by the 
KMS results In the following response: 

Step 1; The KMS Informs the KC that the "next” available 
record In the R8 that contains records of 
the type CIT, RUN. unit, type is to be passed to the 
user. Note that the type of the current of run 
unit does not matter In this case. 

The GET record.type statement is identical to the 

GET option alone, with the exception that the user specifies 

a particular record type. In this case, the KMS must 

determine if the types of the current of run unit matches 

the record type specified before issuing instructions to the 

KC, Also, every data Item Is returned to the user. 

Returning to our example In section C,4, the "GET 

SP" statement causes the return of the record, <S4,P2,200>, 

to the user the first time the GET Is issued and each of the 

other records In sequence as the loop continues, 

2, Xbft SEX ,Xt«Ba S&ataBft&X 

Unlike the other GET options, this statement causes 

specific data items to be returned to the user. The syntax 

of the statement Isi 

GET iteml, ,,, ,ltemn IN record.typel , 
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The KM5 must compare the record. type to the current of run 
unit and also ensure that the data items listed match the 
data items in the record type specified# Once this is done 
and is successful, the KMS Issues instructions to the KC 
just as in the above case# Only this time, specific data 
items are returned from the records accessed# 

As an example, suppose we wanted only the PNO values 
from the SP records. The value returned from our last 
example would be P2, with subsequent GET statements 
returning each PNO value in succession, 

E# MAPPING THE DATA-UPDATING STATEMENTS 

In this section, we examine the CONNECT, DISCONNECT, 
STORE, MODIFY, and ERASE Statements, At this point, the 
reader should have a basic understanding of the mapping 
process as previously described# Thus, for the saxe of 
brevity, the reader is referred to CRefs# 7, 9, and 123 for 
detailed descriptions of the statements and any restrictions 
Involved with their use# we therefore, confine our 
discussion of these statements to a broad definition, the 
mapping process Itself, and in most cases, an example# 

1 # Xb« CQUUECX StatiAftot 

The CONNECT Statement is used for manual insertion 
of the current record of run unit into the current 
occurrences of the set type(s) specified. The syntax is: 

CONNECT record. typel TO set.typel, •#• ,set.typen# 
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This statement requires that the record-typel record be a 
member of the sets specified and also have an Insertion 
clause of MANUAL for those sets. 

The CONNECT statement maps directly to the ABDL 
UPDATE request. The UPDATE format Is: 

UPDATE Query Modifier 

In the case of the CONNECT, the mapping Is very simple. 
First, the KMS replaces CONNECT by the word UPDATE, Then, 
the type and database Key of the record to be Inserted Is 
taken from the CIT to form the query ((TYPE = record. typel ) 
and (DBKEY s CIT,RUN.UNIT,dbkey) ) , Finally, In order to 
construct the modifier, the KMS get the database Key of the 
owner of the current occurrence set. typel from the CIT, The 
KMS then forms the modifier, (MEMBER, set. typel * 
CIT, set. type!, owner. dbKey) for each set type specified. 
Each set type specified has Its own complete UPDATE request 
generated , 

One might asK, why use an UPDATE Instead of an 
INSERT request, well, the difference Is that the CONNECT 
statement Involves records already In the database. And, 
because the Keyword, kmembEP, set. type, null>. Is In the 
record whose connection value Is NULL, It becomes a simple 
matter to just update that particular Keyword, thereby 
connecting the record, we recall that In an attrlbute»based 
database. Keywords, not pointers, are used to connect one 
record to another. The INSERT statement on the other hand. 
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Thus, the 



involves records not already In the database, 
completely translated CONMECT statement is: 



UPDATE ((TYPE a record. typel) and 

(DBKEY a CIT , RUM.UMIT , dbkey ) ) 

(MEMBER , set. type! a CIT, set. typel , owner. dbkey) 



2. Zbft OXSCQ{)ifii£CI Statftaaot 

The DISCONNECT Is just the opposite of the connect 
statement. It causes the current record of the run unit to 
be disconnected from the set listed. The set occurrences 
selected are determined by the current of set type 
indicators. Since several set types may be listed In the 
statement, only one statement Is needed in order to make 
several removals. The records still rema!n in the database. 
They are simply disconnected from specific sets. The syntax 
is : 



DISCONNECT record.typel FROM 
set.typel, ,,, ,set.typen. 



The DISCONNECT Statement requires that record.typel 
be a member of the set types listed, and that the record be 
removed from the set occurrences that are current. Because 



of the way 


we 


represent set 


membership 1 


n the attribute- 


based record, 


this 


task is very 


simple. 


Since we 


are 


disconnecting 


the 


current of 


run 


unltr and 


it contains 


the 


database keys 


of 


the owners 


of 


the set 


occurrences 


it 


belongs to. 


and 


since each 


record can 


only be in 


one 


occurrence of 


the 


same set type 


(pairwise di 


s jointness) , 


the 
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maPDlng process is direct. We simply form an UPDATF request 
for each set type listed. Thus, the keyword, 
<M£MBER , set.typel , owner«dbkey> , is modified, and becomes the 
keyword, <mEMBER , set.typel , null>. To accomplish this, the 
KMS forms the request, 

UPDATE ((TYPE b record. typel) and 

(DBKEY = CIT,RUK'.UNIT,dbkev) ) 
(MEMBCR.set.typel s NULL) 

and passes It to the KC for execution* 

3, Xbfi MQOIKX 

The MODIFY statement causes the entire current 
record of the run unit to be modified or specific data Items 
In that record to be modified* The syntax Is either, 

MODIFY record. typel , or 
MODIFY Iteml, **, ,itemn IN record. typel , 

This statement also, has a rather straightforward 
mapping to the ABDL UPDATE request. The statement assumes 
that the user has supplied the necessary data Item values 
for modification In record.typel record template In the 
UWA, Therefore, the job of the kms portion of the Interface 
Is to get this user supplied Information and form the 
following UPDATE request for each data item to be modified! 

UPDATE ((TYPE » record.type 1 ) and 

(DBKEY « CIT,RUN.UNIT,dbkey) ) 

(data iteml s user value for 1), 

As an example of this process, consider changing the STATUS 
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and CITY attributes of supplier S4 from 20 and 'London' to 
15 and 'Chicago', resoect Ively , The CODASYL request Iss 

MOVE S4 TO SNO IN S 
MOVE 15 TO STATUS IN S 
MOVE 'Chicago' TO CITY IN S 
FIND ANY S USING SNO IN S 
MODIFY STATUS, CITY IN S, 

(Note: The SNO numbers In this example are unique,) Once 
again the move statements set up tne S record template for 
use by holding the new values for the S4 record. The FIND 
statement establishes the S4 record as the current record of 
the run unit. The KMS then responds to the MODIFY statement 
by forming the following two UPDATE requests and passing 
them to the KC for execution, 

UPDATE ((TYPE s S) and 

(DBKEY = dbicey of S4)) 

(STATUS » 15) 

UPDATE ((TYPE « 8) and 

(DBKEY e dbKey of S4)) 

(CITY * 'Chicago') 

If the entire record was to be changed, the first option 
would nave been used, requiring the KMS to form an UPDATE 
request for each data Item In the S record type, 

4, x&A sxoae s&atAttc&ts 

The STORE Statement Is used In the CODASYL«>DML to 
Insert a new record Into the database. Before a new record 
can be inserted though. It must be constructed. This taxes 
place In the UWA, The syntax for the STORE Is: 

STORE record.typel 
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In mapping the STORE statement, care must be 



exercised 


In determining 


the 


prooer set 


occur 


rence In which 


to place 


a record. If It 


Is 


a member 


reco 


rd. 


Tnls Is 


necessary 


only in the 


case 


of automatic 1 


nsertlon. The 


Interface 


must have access 


to the 


or Igi 


nal 


database 


dcscrlpt 1 


on in order 


to 


determine 


the 


set 


selection 


criterion 


for each new record 


to be inserted 


• 


The three 


criterion 


arei by APPLICATION 


, by STRUCTURAL, 


and 


by VALUE, 


Each of 


these requires 


a 


slightly 


differ 


ent 


mapDlng, 


Therefore 


, we examine each 


Individually, 









In addition to the set selection criterion, the 
Interface must determine If any data Items of the record 
being Inserted has a DUPLICATES NOT ALLOWED clause assigned 
to It, In the case that such data items exist, the 
Interface must form a RETRIEVE request to determine the 
existence of records In the database that may already have 
items with the same value as those in the record that Is 
about to be stored. Thus, each STORE statement consists of 
at least one ABDL RETRIEVE and one Abdl INSERT request, we 
shall see, however, that additional RETRIEVE's are necessary 
for the set selection criterion of structural and value, 
a. The STORE»by»Appllcatlon Statement 



This method of 


set 


selection assumes 


that 


the 


proper occurrences 


of sets 


are Indicated in 


the 


CIT. 


Therefore, the KMS 


forms 


two 


requests, the RETRIEVE 


to 
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determine the status of duplicates, and the INSERT request 

which stores the record. The process is as follows: 

step 1: The kms forms the RETRIEVE below with the search 
based on all data Items deslonated to have 
DUPLICATES NOT ALLOWED, The values for these Items 
In the new record are supplied by the user via 
the UWA record template, 

RETRIEVEC (TYPE « r ecord.type I ) and 

(data Iteml s user valuel)) 

(DBKEY) [by OBKEY] 

Step 2: The KMS forms the INSERT request 

INSERT(<TYPE,record.typel>,<DeKEY,t*»>, 

<data Iteml, user valuel>, 

<M.EM5ER, set-typel , set.typel ,owner«dbKev>) 

and forwards both requests to the KC for execution. 

Step 3; The KC Issues the RETRIEVE request. If the RB 
returns with no DBKEYs, then the INSERT request Is 
executed. Otherwise, the INSERT Is not executed 
and an error condition exists. 



b. The STORE-by-Value Statement 

The by-VALUE set selection criterion means that 
the set occurrence we need has a data item whose value Is 
equal to the value in the specified UWA record template 
which has that data item as one of Its fields. The reader 
Is referred to Figure 10 for the syntax of the set selection 
clause of sets S**SP and P-SP, as examples. This type of 
STORE requires that the data Item In question have a 
DUPLICATES NOT ALLOWED Clause also, and that the user 
initialize the data Item In Its UWA record template oefore 
Issuing the STORE request. 

The by-VALUE criterion therefore, places the 
additional requirement on the Interface of locating the 
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owner of the proper set occurrence before the new record can 
be Inserted into the database. This is accomplished by the 
issuance of a second retrieve request by the kc if the first 
RETRIEVE, as mentioned above, returns null. The steps in 
the process are: 



Step 1: The KMS forms the first RETRIEVE as above. Then 
for each set type in which the new record is a 
member, a RETRIEVE request is formed to oet the 
owner database tcey. The request is: 

RETRIEVEC (TYPE = owner tvpe) and 

(search item a user value)) 

(DBKEY) (by D8KEY] , 

Step 2: The KMs forms the following INSERT request: 

INSERT (<TYPE,record.typel>, 

<DBKEY,*»»>, 

<data iteml,user valuel>, 

<MEMBER,set«typei ,»»»>) 



Steo 3: The KC executes the first RETRIEVE to determine if 
duplicates exist. If not, the remaining RETRIEVES 
are executed In turn to get the database keys of 
the owners of the set occurrences to which the new 
record belongs. Once these values are returned, 
the KC finishes building the INSERT request, and 
executes it, 

c. The STORE»by-Structure Statement 

The by»STRUCTURAL set selection criterion is 
similar to by-VALUE except that the proper set occurrence is 
selected by comparing a data item value in one record type 
to the value of that same data item in another record type. 
From our sample database, we could have a by«STRUCTURAL 
clause indicating that the SNO value in S must equal the SnO 
value in SP, Thus, we must search for an SP record 
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occurrence with the same SNO value as that in the S template 



In the UWA, Once again, this data Item must have a 
DUPLICATES HOT ALLOWED specification. 

The mapping here Is Identical to that for the 
by-VALUE case except tnat the second through 1th RETRIEVES 
are based on equality of values In seoerate records. Since 
the Idea Is the same, we will not give the specifics of the 
mapping here. It Is presented In detail In the Appendix, 

5, Ibe ERASE SEAtfiSftO&S 

The ERASE Is the final CODAsYL-DML statement we 
consider for the MLDS networJc interface. As Implied, it is 
the statement that causes deletion of records from the 
database. There are two options with this statement, as 
previously discussed In Chapter 2, we begin with the simple 
ERASE, The syntax for this ERASE statement Is: 

ERASE record.typei 

The ERASE without the ALL option deletes one record 
from the database, namely, the current record of the run 
unit. The only requirement is that the record Is not the 
owner of a non-empty set. This means that in mapping this 
statement, we need to issue a RETRIEVE request prior to the 
deletion request to determine if there are any sets whose 
members are connected to this record. Therefore, for each 
set type in which the current of run unit is an owner, we 
have a predicate in the RETRIEVE query of the form: 
(MEMBER, set. type! ** ciT,RUN.ONIT,db<ey) , The request is: 
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RETRIEVEC (MEMBER, set-tyoel n C I T , Ru N.UN IT . dbicey ) and 

• and 

(MEMBER, set. typen s CIT, RUN. UNIT, dbkey) ) 

(DBKEY) (by DBKEY) , 

The next step In the mapping process is to form a 
DELETE request that deletes the current of run unit. That 
request is: 

DELETE((TYPE = CIT.RUN.UNIT, type) and 
(DBKEY « CIT.RUN.UNIT.dbkey) ) , 

So# the KMS In this case Issues two ABOL requests to the KC 
for execution. The KC would execute the RETRIEVE first. If 
it results in a NULL RB, then the DELETE Is executed. 
Otherwise, the ERASE falls. 

The second ERASE under consideration is the ERASE 
with the ALL option. The ERASE ALL syntax is: 

ERASE ALL record.typel , 

As mentioned in Chapter 2 , this option Is IKe a "vacuum 
cleaner" In that It deletes every record In the hierarchy 
starting with the current record of the run unit, Tne 
difference between the mapping of this statement and the 
previous ERASE Is that, RETRIEVES must be formed to get the 
database keys of each member of every set that the current 
of run unit owns, and then RETRIEVES are formed recursively 
thereafter for the members of lower level sets until the 
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leaves of the hierarchy are reached, in addition to these 
RETRIEVE requests, a DELETE request Is needed for each 
member of every set connected to the current of run unit and 
the current of run unit Itself, As one can see, this could 
become quite complex. Therefore, we briefly decribe the 
alqorlthm, and refer the reader to the Appendix for the 
details , 



In mapping the ERASE ALL, the KMS forms a RETRIEVE 
request to get each member of every set owned by the current 
of run unit. It then forms a DELETE for each of these 
members. Once it has taken care of the first level, the KMS 
proceeds to form requests which erase all of the descendents 
In the same fashion by calling a recursive procedure called 



"erase 


•all". Finally, the KMS 


forms 


a DELETE 


reque 


delete 


the current record of the run 


unit as in 


the 


pr 


ERASE, 


This concludes the 


desclptions of 


the 


m 



process from CODASYL-Dml to ABDL, 
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IkieLCMStlZAIXOti COtiSlOE&AZXQIiS 



V. 

In Chapter 1, we provide a brief description of the four 



mod 


ul 


es 


in 


clud 


ed in 


the 


COOASYL 


la 


ngu 


age Interfa 


ce , 


name 


lYr 


the 


1 


an 


quag 


e 1 


nterf 


ace 


layer 


(LI 


L), 


the 


kern 


el 


mapp 


ing 


sys 


te 


m 


(KM 


S), 


the 


kern 


el contro 


lie 


r (KC), 


, and 


the 


ker 


nel 


for 


ma 


tt 


Ing 


sys 


tem 


(KFS) 


, In 


th 


is 


chapter , 


we 


pres 


ent 


con 


si 


de 


rati 


ons 


for t 


he Im 


plementat i 


on 


of the 


KMS 


and 


the 


KC, 



A, THE KERNEL MAPPING SYSTEM (KMS) 

The KMS is the second module in the mlds COOASYL 
interface. It is called from the language interface layer 
(LIL) when the LIL receives CODASYL input requests from the 
user. In this section# we discuss the specification of the 
K.MS (see Appendix) for the network (COdASYL) Interface, we 
describe its operation, present a conceptual view of its 
data structures, and give an example of the KMs translation 
process. Implementations of the KMs for the DL/I and SOL 
Interfaces can be found in [Ref, 5:pp, 4$»80) and CRef, 
6:pp, 47»683, respectively. These implementations provided 
the basic framework for the design of the CODASYL KMS, 

The KMS must perform the following functions* (1) parse 
the request to validate the user^s CODASYL syntax, and (2) 
translate, or map, the request to equivalent ABOL requests. 
Once the necessary ABDL requests have been formed, they are 
made available to the kernel controller (KC) for execution. 
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!• Xbft KMS £AC£fi£/l£a&sXalOS 

The grammar-driven parser Is the most Important 
aspect of the KMS, The Yet-Another-Comoller Compiler (YACC) 
[Ref, 14] Is an Ideal choice for the construction of the 
parser, YACC Is a program generator designed for syntactic 
processing of token streams, YACC functions as follows: It 
must be given a specification of the Input language 
structure (a set of grammar rules)# the code tnat is to be 
Invoked when the grammar rules are recognized, and a low- 
level Input routine that generates tokens from a regular 
expression input. Given these inputs, YACC generates a 
program that syntactically recognizes the input language, 
and causes specific user code to be Invoked, as required, 
throughout the recognlton process. The user's code here Is 
the code that performs the CODASYL-DMl to ABDL translation. 
The Lexical Analyzer Generator (LEX) tRef, 15J is the low- 
level Input routine that we propose, LEX Is a program 
generator designed for lexical processing of input character 
streams. It takes regular expressions as input, and 
generates a program that partitions the Input stream into 
tokens. These tokens are then output to the parser for 
further processing. 

The parser produced by YACC consists of a finite- 
state automaton with a stack. It performs a top-down parse, 
with lef t-to-right scan and one token look-ahead. Control 
flow within the parser begins at tne highest-level grammar 
rule. It then descends through the grammar, hierarchically. 
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calling lower- and lower-level grammar rules whlcn search 
for the appropriate tokens In the input streams. As these 
tokens are recognized, some portions of the 
mappino/translat Ion code may be Invoked directly, Tn other 
cases, these tokens are propagated oack up the grammar 
hierarchy until a higher-level grammar rule Is satisfied. 
Once a rule Is satisfied, further translation can be 
accomplished. When all of the necessary low-level grammar 
rules have been satisfied, and control has propagated back 
UP to the highest-level rule, the parsing and mapping 
process Is complete. In section B, we provide an example of 
the parsing and translation process, 

2, XUS Data Stsuc&ucaa 

The KHS needs several different data structures. 
However, we confine our discussion here to the structures 
which carry the information necessary for the proper 



execution 


of 


the translated 


requests , 


The structures 


that 


fall into 


this 


category, are 


the CIT 


structure, and 


the 


request 


nodes 


which are passed to the 


KC for execution 


. A 



description of the minimum requirements for these structures 
Is given below. 

The CIT Is described In Chapter 4, This structure 
carries all of the currency Information for a particular run 
unit, and Is vital to the proper translation and execution 
of CODAsyL statements. The LIL of the interface Initializes 
the CIT, The KMS has read access to the CIT at all times, 
while all updates of the CIT are done by the KC only. In 
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the following sections, we discuss each of the data 
structures that are directly related to the parsing and 
translation process, 

a. The 'flnd.node' Data Structure 

The find, node is created and used any time that 
a CODASYL FIND stateirent is mapped by the K^S, Since we are 
considering the Implementation of six different FIND 
formats, we must ensure that the find. node has at least four 
fields, one Identifying the node as a flnd.node, a second, 
specifying the type of FIND statement that must be executed, 
l.e,, FIND ANY, FIND CURRENT, FIND OWNER, and FIND WITHIN, 
one field to indicate the set type involved, and one field 
to Identify the record type used in the statement, 

flnd.node 

I FIND I 
I type of FIND I 
I set type I 
I record type I 
I f I 
I f I 
I f I 
I I 
I pointer to ABDL requestCs) I 

Figure 17i The 'flnd.node' Data Structure, 

In addition to the above information, each 
flnd.node must also have a field which contains a pointer to 
the specific ABDL request that resulted from the mapping 
process, with regard to the FIND CURRENT request and the 
FIND DUPLICATE request, no ABDL request is generated. 



69 



Therefore, the pointer would be null. Figure 17 above 
illustrates the type of structure described, where the dots 
represent any additional iFplementat ion*dependent 

Information which might need to be included, 
b. The 'qet.node' Data Structure 

The get node carries the Information that the KC 
needs in order to return the proper data to the user. It 
must have a field identifying it as a get node and a field 
identifying the type of GET format being used. 

Additionally, a field identifying the record type in 

question must also be included. In the case of the GET 
item. list format, the node should Include a pointer to a 
list of data item values to be returned. If the format is 
GET record. type, the pointer field would be NULL, and the KC 
would return all attributes of the record. The same is true 
for the simple GET format. Figure 18 is an example of this 
type of structure, 

get. node 

I GET I 

I type of GET I 

I record type I 

I • I 

I • I 

I t I 

I I 

I pointer to list of data I 

I items to be returned I 

Figure 18i The 'get.node'' Data Structure, 
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c. The 'connect.node ' Data Structure 

The connect.node Is created and used whenever a 
CONNECT statement is mapped by the KhS, There are two 
primary fields In this node. The first field identifies the 
node as a connect.node , The second field Is a pointer to 
the list of ABDL UPDATE requests generated by the KMS durlno 
its grammar-driven parse. This list may contain one or more 
requests depending upon the number of sets that the record 
must be connected to, as described in Chapter 4, Under the 
current implementation of the MBDS, a separate UPDATE 
request must be executed for each attribute in a record that 
is to be changed. Thus, the need for multiple UPDATE 
requests. Recall, that the attribute to be changed in this 
case is the MEMBER, set.type attribute. Figure 19 shows the 
basic structure for this node, 

connect.node 

I CONNECT I 

I t • 

I • I 

I • I 

I I 

I pointer to list of UPDATE I 
I requests I 

Figure 19i The ^connect.node' Data Structure, 

d. The 'dlsconnect.node' Data Structure 

The disconnect.node is created and used whenever 
a DISCONNECT Statement Is encountered by the KMS, The 
fields of this node are exactly the same as those of the 
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connect.node , In this case however# the value of the 
attribute MEMBER, set .type Is set to NULL, disconnecting the 
record from designated set occurrences. Once again, we have 
an Identifier field, and a list of UPDATE requests. 



also very similar to the connect. node . It Is created 
whenever a MODIFY statement Is encountered by the KMS, It 
has two fields, an identifier field, and a pointer to a list 
of UPDATE requests. The UPDATE requests In the modify. node 
are used to alter the value of specific dA&a i£a& attributes 
within a particular record. The number of requests on this 
list can vary from one to the maximum number of data Items 
In the record, depending on the MODIFY format chosen by the 
user. 



data structures presented so far. It must contain at least 
four fields. The first Is the identifier field. The second 
field Is a pointer to a RETRIEVE request, This request Is 
generated by the KMS In order to determine the existence of 
duplicate values for data items declared to have DUPLICATES 
NOT ALLOWED In the database schema. The third field of 
Importance relates to the set selection criterion for the 
record being stored. It is generated to retrieve the owner 
database KeyCs) of the proper set occurrence(s) for the new 



e. The 'modi fy. node' Data Structure 



As with the dlsconnect.node , the modify. node Is 




f. The ilstore.node'j Data Structure 

The store. node Is the most Interesting of the 
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record. This request is only generated in the cases of the 
by-VALUE and by-STRUCTURAL set selection crlterions, 

store.node 

I STORE I 

I pointer to duplicate RETRIEVE request I 

I pointer to list of set select RETRIEVE | 

I requests I 

I • I 

I t I 

I f I 

I I 

I pointer to INSERT request I 

Figure 20: The 'store.nooe' Data Structure, 

The final field required for the store, node is a 
pointer to the INSERT request which will actually cause the 
record to be placed into the database. Figure 20 above is 
an illustration of this data structure. As mentioned 
before, the dots in the figure represent additional 
implementation-dependent information. Should the set 
selection criterion be by APPLICATION, the second RETRIEVE 
pointer would be NULL, 

g. The 'erase, node* Data Structure 

The final data structure we discuss is the 
erase,node. This node is created whenever an ERASE 
statement is mapped by the KMS, If the ERASE without the 
ALL option is mapped, the erase.node must contain the 
following four fields. First, it must contain an identifier 
field. Second, it must contain a type field with a value of 
NULL, indicating that it does not have the ALL option. The 
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third field In this node must be a pointer to the RETRIEVE 
request that will determine if the record being deleted owns 
a non-empty set. Should this request return NULL, the KC 
would execute the request stored In the fourth field. This 
Is the field containing a pointer to the DELETE request that 
will delete the current record of the run unit. Figure 21 
gives a representation of this structure, 

erase.node 

I ERASE I 
I type of ERASE I 
I pointer to RETRIEVE request I 
I f I 
I • I 
I • I 
I I 
I pointer to run.unlt DELETE i 

Figure 21: The •erase.node' without the ALL Option, 

The erase.node created for the ERASE vltU the 
ALL option will be considerably more complex than the 
previous case. First, there must be an Identifier field and 
a type field. Then there must be tw© pointer fields. The 
first pointer field will point to tne list of RETRIEVE 
requests generated to get all the descendents of the record 
being deleted. The second pointer field will point to the 
list of DELETE requests generated for each of the descendant 
records,’ Finally, the last field In the structure should be 
a pointer to the DELETE request that deletes the current 
record of the run unit. Figure 22 Is an example of this 
structure. 
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erase.node 



I ERASE I 
I type of ERASE (ALL) ( 

I pointer to descendent Retrieves I 
I pointer to descendent deletes I 
I t I 
I t I 
I • I 
I I 
I pointer to DELETE I 

Figure 22: Tne 'erase.node' with ALL Option, 

B, THE MAPPING PROCESS: AN EXAMPLE 

In this section, we present an Illustrative example of 
the parsing and translation processes within the kms. 
Recall from the previous chapter, that not all of the 
features of CODASYL are Incorporated In our specification. 
Additionally, since we have thoroughly covered the mappings 
In the previous chapter, we do not discuss these 
translations In detail. 

As an example of the KMS mapping process, we use a 
simple CODASYL MODIFY request, we begin our example by 
showing the dml.statement portion of the KMS, we then step 
through the grammar and demonstrate relevant portions of our 
design In a system specification language (SSL), The reader 
should note that throughout the example, we only show the 
portions of the SSL that would actually be executed. The 
entire kms design Is shown In the Appendix, The portion of 
the grammar relevant to this example is shown In Figure 23, 
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In Floure 23, we have Included the qrammar rules only, 



and 



not the code to be invoiced as each rule is satisfied. 



statement: ddl.statement 
I dml 



dml: dml. statement 


t dml dml. statement 

• 

9 


dml. Statement : 


set. flag 


1 


move 


1 


get 


1 


find 


1 


store 


1 


connect 


1 


disconnect 


1 


erase 


1 


modify 


1 


perform. loop 


1 

; 


if-then 


modify: MODIFY 


item-list IN 


1 MODIFY 

t 


record-type 



record^type 



Item.llst: item. name 

I Item.llst COMMA item-name 

; 

record. type: IDENTIFIER 

; 

item.namei IDENTIFIER 
t 



Figure 23: 



The KMS dml. statement Grammar, 



The source CODASYL procedure we use 



for our example is: 



MOVE 100 TO OTY IN SP 
MODIFY OTY IN SP, 



Before giving the ABDL equivalent of this request, however, 
we must maice the assumption that the record being modified 
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Is the current 



record of the run unit. 



Me also assunne that 



the database key for this record is 10, with these two 
assumptions In mind, the AB0l< equivalent of the MODIFY 
statement Is: 

[UPDATE ((TEMPLATE = SP) and (DbKEY 2 10)) 

(OTY 3 100)3, 

For the sake of brevity In our example, we will not qo 
through the mapping process for the MOVE statement. The 
reader need only be aware that the new value for the 
attribute QTY In the record template for record type SP, has 
been set to the value, 100, by the previous 
parse/translation. Now, we may proceed with the mapping of 
the MODIFY statement. 

At the beginning of the mapping process, the oarse 
descends the grammar hierarchy searching for tokens In the 
grammar rules which match those In the Input, Notice that 
the first rule to be tried Is the ddl.statement rule. As 
the parse descends the ddl, statement rule, hierarchically, 
there are no tokens which match the example Input stream. 
Thus, the ddl.statement rule is not satisfied, and the parse 
begins again at the dml rule. 

When the dml rule is called. It Immediately calls the 
dml.statement rule, 
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dml.s tatement : set.flag 

I move 
I get 
I find 
I store 
I connect 
I alsconnect 
I erase 
I modify 
I perform. loop 
I If. then 
f • 



The dml. statement rule 
set. flag rule Is not 
is called. It too, Is 
checking each success 
the following rule: 



then calls the set*flag rule. The 
satisfied, however, and the move rule 
not satisfied. So, the process of 
Ive rule is continued until we reach 



modify: MODIFY 

< 

select. list B NULL 
} 

Item. list IN record. type 

< 

/* error checks are made here ♦/ 
alloc and Inlt new 'modify' node 



for (each data. Item on select. list) 
alloc and Inlt new abdl.str 
/* form UPDATE request ♦/ 
copy ” (UPDATE ((TEMPLATE b 'record.type' ) 
and (DBKEY B CIT, RUN. UNIT, dbkey) )" 
to abdl.str 

get 'Item. value' from move. list 
concat " ( 'data.item' b 'item. value' ) ) 
to abdl.str 

connect abdl.str to 'modify' node 
end. for 
end. else 
> 

I MODIFY record.type 

t • 

The modify rule looks for the token, MODIFY, in the Input, 
Since It Is present, the first portion of the rule matches. 
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and the code following the token In the rule is invoked. 
This code simply resets a local list which win eventually 
contain the names of the data items which are to oe 
modified , 

The next rule called Is the rule. This rule 
searches for a list of Identifiers In the Input by calling 
the Item.name rule, and recursively calling item.llst, as 
Indicated, In our example, the single identifier, QTY , 
satisfies the first portion of this rule, namely, item, name. 
Thus, the Item, list rule Is satisfied* The syntax for the 
Item.iist rule is: 



Item, list: Item. name 

< 

add the ltem,name 
to select.llst 

> 

Item.iist COMMA item.name 

< 

add succeslve 

Item.name to selec«llst 

} 

t • 



The next 


portion 


of the modify rule is 


the 


token. 


IN, 


This token 


matches 


the token, 


IN, in the 


input 


stream. 


and 


the parse continues. 


Finally, 


the last 


portion of 


the 



modify rule which must be satisfied is the rule. 
This rule is satisfied by matching the identifier, SP, In 
the input, with the token, lOENTIFlgP, in the record, type 
rule. After matching these two, the entire modify rule is 
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satisfied, and the Invocation of the remaining mapping and 
translation code following the rule ta>ces place. 

The mapping and translation occurs as follows. First, a 
series of checks are made to determine If the record being 
modified is the current record of the run unit. If the new 
value(s) have been placed In the record temolate, and If all 
of the items identified In the item list belong to the 
record In guestlon. Then, a modify node is created. 
Following this step, an UPDATE request Is generated for each 
of the data Items being modified. Finally, each of the 
update requests are connected to the modify node for 
execution by the KC, with the mapping and translation code 
executed, the modify rule Is completely satisfied, and 
control propagates back up the grammar hierarchy to the dml 
rule which checks for more Input, 

As one can see, quj^te a significant amount of worjc Is 
done by the KMS In preparing requests for use by the kc, We 
feel that by adequately providing Information to j^he KC, we 
greatly reduce the amount of work that must be done by the 
KC, This means less coding for the implementor and should 
lead to less complexity in the KC, 



C, THE KERNEL CONTROLLER (KC) 



The KC 


is 


the 


third 


module 


in the 


MLDS CODASYL 


interface. 


It 


Is 


called 


by the 


language 


Interface layer 



(LID when a new database is being loaded, and is called by 
the kernel mapping system (KMS) when an existing database Is 
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being manipulated. The KC Is the module which performs the 
tasic of controlling the submission of ABDl transactions to 
the multl»bac)cend database system (mbPS) for processing. 
Implementations of the KC for the DL/I and SQL interfaces 
can be found In TRef, 5:pp, 84-105J and CRef, 6:po, 69-8Q), 
respectively. 

The KC must perform the following functions: Cl) submit 
transactions to the MBDS, (2) receive and store results of 
transactions, (3) update the currency Indicator table, and 
(4) cause the proper data to be returned to the user, 

1. Xba &tsuctust t&ft KC 

Because of the large number of types of transactions 



that the 


KC 


must 


process, we 


suggest 


that the overall 


structure 


of 


the 


KC be based 


on the 


"case** control 



structure. At the top of the control structure is a master 
control procedure which Is responsible for Initialization of 
variables, pointers, and data structures, as well as, 
deciding the type of ABDL transaction that is being 
processed. Recall that there are two major types of 
transactions, creation of a new database, and manipulation 
of an existing database. Thus, a two element case is 
required in the master control procedure. These cases are 
then used to call subsequent procedures and functions which 
handle the transactions which fall under the above 
categories , 
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dlff leu 
loading 
(MBDS) , 
for mas 
transac 
the new 

necessa 
mass St 
In t Im 
however 
require 
to load 
databas 
the new 
control 



also 

retrlev 

However 

structu 

request 

These r 

within 



a. Creation of a New Database 

The creation of a new database is the least 
It transaction that the KC win handle. It Involves 
the CODASYL schema created by the KMS into the KDS 
In Its attr lbute*based form. It Is also responsible 



s storage of new records during a database creation 
tlon. Thus, the KC must also assign database Keys to 
records throughout this process* 

Currently, work Is being done on the algorit hms 
rv to accomplish the transformations above and the 
orage requirement. This worK win not be completed 
e for Inclusion In this thesis* Suffice It to say, 
, that once the worK Is completed, the only 

ment of the KC in this case, is to call a procedure 
the database schema, call a procedure to load the 



e descriptor file, and then ceil a procedure to l^jid. 
database* Once these procedures are executed, 
is returned to the LIL, 

b. Manipulation of an Existing Database 

The manipulation of an existing database can 
be divided Into subleases. There are the data 
al requests and the database update requests, 

, all of these can be handled by a single case 

re. Recall that each time the KC is called, a 

node of some type Is made available to the KC, 

equest nodes are then used to determine which option 
the case structure to execute* The structure Is 
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Illustrated In Figure 24, in the following sections, we 
present the procedural requirements for each type of data 
manipulation transaction. 



case op.type of 

create.db: call load.schema 

call load„descrlptors 
call loadwdp.recs 

9 

find! case type of 

any: call flnd.any 
current! call flnd-current 
duplicate! call f lnd«dupllcate 
(first, last, 

next, prior): call find.conseq 
owner: call flnd^owner 
end„case; 

(connect , 

disconnect , modify) ! call update^db 

; 

store: call store.rec 

; 

erase: call delete.recs 

; 

get: call get.rec 

; 



Figure 24: The KC Control Structure, 



(1) XUa esoCAdusAft. There are six basic 
types of FIND requests utilized In our system. The first of 
these Is the FIND ANY request, upon encountering a 
flnd^node whose type field Is any, the flnd.any procedure Is 
called. This procedure sets up the request buffer to 
receive any results that may be returned. It tnen Issues 
the request to the KDS, Upon return from the KDS, the 
flnd.any procedure must update the CIX, based on the type 
and database Icey of the record that Is the first record In 



83 



the request buffer, A pointer Is then set to point to this 
record In preparation for returnlnq It to the user. The 
record Is not returned though, unless the user Issues a GET 
request , 

If the request Is a FIND CURRENT request, 
the find. current procedure Is called. Its job Is quite 
easy. It must simply update the CIT, oy setting the current 
of run unit Indicator to the type and database key of the 
current record of the set type specified In the request 
node. 

When the request Is a FIND DUPLICATE 
request, the f Ind.dupllcate procedure Is called. This 
procedure assumes that the records being requested are 
already In a request buffer. Thus, the only Information 
required from the find. node Is the record.type being 
searched for, the set. type of Interest, and the data Item 
values on which the search Is baaed. The procedure locates 
the request buffer, and sets a pointer to point to the first 
duplicate record found. This record then becomes the record 
returned when the user Issues a GET request. The procedure 
also updates the CIT accordingly. 

The next type of FIND request Is the FIND 
FIRST, LAST, NEXT, or PRIOR, In these cases. If the type Is 
first, last, next, or prior, the flnd.conseq procedure Is 
called. It bases Its performance on the type of the 
find. node. If the type Is next or prior, the procedure 
assumes that the records are already in a request buffer. 
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It looKs for the correct request buffer based on the 
record.type specified in the find.node, and sets a pointer 
to point to the next or prior record relative to the current 
record of the set type this buffer is holding. In other 
words, each record in the buffer is a member of the current 
set type occurrence, and the find.cohseq procedure simply 
points to the record before or after the current record for 
that set. Once again, this is the record returned when the 
user Issues a GET request. 









If the type of the FIND is first 


or last. 


the find. 


conseq 


procedure does 


the following. 


First, it 


checks to 


see 


if 


a request buffer 


exists for the 


set type 


requested 


in 


the find.node. If 


no such buffer 


exists, the 



procedure creates a request buffer and Issues the RETRIEVE 
request attached to the flnd.node. The results of the 
request are then placed in the new request buffer, and a 
pointer is set to point to the "first" or "last" record in 
the set for return to the user. 

The next type of FIND request is the FIND 
OWNER, When this is the type of the flnd.node, the 
flnd.owner procedure is called. It's function is fairly 
straightforward, A request buffer is created to hold the 
record that is the owner record of the set type Indicated in 
the find.node. The flnd.owner procedure then Issues the 
retrieve request attached to the flnd.node, and prepares the 
record for return to the user. 
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the KC, i 
the flnd.wl 
a request 
Issues the 
find-node, 
record In t 
be returne 
should be n 
unless a c 
find-node 1 



The final 
s the FIND WITHIN 
thin procedure Is 
Duffer for the 
RETRIEVE request 



type of find requ 
CURRENT request 
called. The pr 
storaqe of reco 
associated ivl 
set to po 
that t 
Issued 
the 
been 



Again, a pointer Is 
he request buffer In order 
d when a GET request Is 
oted that In each case above, 
urrency suppression list has 
n question. 



est, expected by 
, In this case, 
ocedure creates 
rds returned and 
th the current 
int to the first 
his record mlant 
by the user. It 
CIT Is updated 
attached to the 



(2) Xtift C0U2l£Cl, OXSCOUUSCZ, AQd MQOieX 
&£QCftduca&, The connect, disconnect, and MODIFY requests 
are handled by the KC In the same general manner. When 
either a modify-node, a connect-node, or a dlsconnect-node 
Is encountered by the KC, the procedure, update-db, Is 
called. If the node Is a modlfy-node, the KC simply submits 
the attached ABDL UPDATE requests to the KDS for execution. 
After execution, control is returned to the LIL, 

If the node passed to proceddure update-db 
is a connect-node or a dlsconnect-node, all of the above 
applies, except that before giving control to the lil, the 
KC must update the CIT, When a record is connected to a set 
type, that record becomes the current record of the set 
type. When a record is disconnected from a set type, the 
entry in for that set type In the CIT is set to NULL and 
remains so until another record of the set type Is accessed. 
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(3) Ibft SXQfiS e£OcadU£&, When the KC 
recognizes a store.node, the procedure store»rec is called. 
The first task performed by store.rec is to execute the 
first RETRIEVE request attached to the node. This request 
determines if there are records in tne database which have 
attribute values that are not to be duollcated. If the 
request buffer created for this RETRIEVE is PQQ-ftfiQtv et the 
end of execution, there is an error. If the request buffer 
is aoDtv , then store.rec performs in the following manner. 
For each RETRIEVE request on the set select RETRIEVE list, a 
file buffer is created and the RETRIEVE request is Issued, 
These requests return the database keys of the owners of the 
set occurrences to which the new record belongs. 

After execution of the set select RETRIEVE 
list, the procedure store.rec then assigns a database key to 
the new record, and proceeds to complete the INSERT request 
attached to the store. node. It Is very Important that the 
order in which the database keys are accessed from the 
request buffer match the order of the attributes, 
MEMBER, set. typel , in the INSERT request. The INSERT request 
is then Issued, Now, because we have not accessed this 
record previously, and it nas become the current of run 
unit, store.rec must provide a buffer to hold this record in 
case a GET request is Issued immediately following the STORE 
request. An example of this process is warranted at this 
point. Suppose, we desire to store the SP occurrence, 
S5/P6/700, The CODASYL sequence might be* 
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MOVE 'S5' TO SNO IN SP 
MOVE 'P6' TO PNO IN Sp 
MOVE 700 TO OTY IN SP 
MOVE 'S5' TO SNO IN S 
MOVE 'P6' TO PNO IN P 
STOHE SP 



The first three moves Initialize the new 
record's data values. The next two move's are used to aid 
In determlnlnq which S and P occurrences the new record 
belongs to, because its set Insertion mode was declared to 
be automatic. The KMS takes this information and the STORE 
5P statement, and produces a store.node containing the 
following: 



(Duplicates RETRIEVE request) 

RETRIEVE ((TYPE b SP) and (SNO » S5) and (PNO 3 P6)) 
(DBKEY) 

(List of RETRIEVES to get owner DBKEYs) 

RETRIEVE ((TYPE = S) and (SNO a S5)) (OBKEY) 

RETRIEVE ((TYPE s P) and (PNO s P6)) (DBKEY) 

(INSERT request for new record) 

INSERT (<TYPE,SP>,<DBKEY,**»>,<SN0,S5>r<PN0,P6>, 
<MEMBER, S-SP, <MEMBER,P-SP, ♦»»♦>) 



We assume, for the sake of our example, 
that the DBKEYs for the owner records are 10(S) and 12(P), 
and that the DBKEY of the new record Is 93, we also assume 
that there is no duplicate SP record in the database. So, 
when store.rec Issues the first RETRIEVE, the request buffer 
returned Is empty, 

Store.rec then proceeds to execute the list 
of RETRIEVES that return the owner ObKeYs of the new record. 
It creates a request buffer for the first retrieve on the 
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list and Issues the request. Once the first request Is 
executed, a buffer Is created for the second request, and 
that request Is executed. The Issuance of these RETRIEVES 
produces the results In the request buffers depicted In 
Figure 25, The procedure store^rec now taices the new DBKEy 
value, and the Information from the request buffers and 
completes the INSERT request, 

I < 10 > I 
i I 

Bufl 

I < 12 > I 
I I 

Buf2 

Figure 25: Bufl and Bu£2 After Execution, 

The final form of the INSERT request Is: 

INSERT (<TypE,5P>,<DBKEY,98>,<SN0,S5>,<PN0,P6>, 
<MEMBER,S-SP, 10>,<MEMBER,P-SP,12>) 

The INSERT request Is then Issued to the KDS, If no 
currency suppression list Is attached to the store^node, the 
CIT Is updated to reflect a change In the S»SP and P-SP 
currency as well as, the current of run unit, A request 
buffer Is also created, and the record is stored In the 
buffer. As one can see, the store.rac procedure can be a 
very comprehensive one. 
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(4) ZbA £fi&S£ S£OCAdu£fi&. 



The ERASE request is 



handled by the procedure, delete, 
erase.node Is NULL, then delet. 
following manner. First, a reque 
the RETRIEVE request attached to th 
the KDS, This request determln 
deleted Is an owner of a non-empty 
buffer Is not empty after execut 
the erase falls, and we have an er 
request buffer Is empty after e 
then delete.recs Issues the DELETE 
erase. node. This request deletes 

run unit. After the deletions, del 
by setting the current of run unit 

Should the type of 
we have a different sequence of 
procedure must create request buf 
request on the descendent retrlev 
It must then Issue each of these 
results, returned DBKEYs, In th 
After the list of retrieves has bee 
procedure then completes the delete 
erase.node and Issues each DELETE r 
execution. Once again, the CIT 
change In currency l,e«, current of 
appropriate. 



recs. If the type of the 
recs proceeds In the 
st buffer is created, and 
e erase. node is Issued to 
es If the record being 
Set, If the request 
Ion of the RETRIEVE, then 
ror condition. If the 
xecutlon of the RETRIEVE, 
request attached to the 
the current record of the 
ete.recs updates the CIT 
Indicator to null, 
the erase. node be ALL, 
events, The delete-recs 
fers for each RETRIEVE 
e list In tne erase.node, 
RETRIEVES storing the 
e proper request buffer, 
n issued, the delete.recs 
requests attached to the 
equest to the KDS for 
is updated to reflect the 
set.types become null as 
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(5) xbfi G£Z Scdcadusfi* The GET reauest is 
handled by the get.rec procedure. This procedure has a 
relatively easy task. It simoly looks at the type of the 
get.node, examines the record.type Involved, and retrieves 
either the entire record of specific fields of the record 
from the request buffer In which the record resides. The 
GET request operates on the current of run unit, so, the 
reauest buffer in question should be the request buffer 
containing the current record of the run unit, provided tne 
current record of the run unit is not null. Finally, the 
reader snouid note that with each of the above procedures, 
deallocation of request buffers when they are no longer 
required, is also an important consideration in this 
process • 
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VI. CQUCLUSIQUS 



As mentioned in the Introduction, the conventional 
approach to database system development has resulted in 
numerous single-model, single-language systems wltn little, 
if any, flexibility or extensibility. In addition, these 
systems are slow compared to the system proposed by this 
research effort. Our system, the multi-lingual database 
system (MLDS), provides an alternative to the development of 
seperate stand-alone database systems wnlch use single data 
models. The MLDS will bring flexibility# extensibility, and 
efficiency to the world of database management. The MLDS 
will be able to execute transactions written in any of four 
well-Icnown and Important data languages, namely, DL/I, SOL, 
CODASYL, and Oaplex, 

In this thesis, we have presented a methodology for 
supporting network database management within the MLDS, 
Specifically, we have provided a data model transformation 
strategy, and a data language translation strategy for the 
network data model and the COOASYL data language, 
respectively, we have presented a design specification for 
the kernel mapping system (KMS) to be used in the CODASYL 
Interface, A discussion of the concepts involved and the 
data structures necessary for the interface to work properly 
has also been presented. 
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One of the deslqn goals of this project was to make the 
Interface as compatible as possible with the designs of the 
DL/I and SQL Interfaces In order to fully utilize existing 
software. The Daplex Interface Is not mentioned here, 
because it Is being developed In parallel with the COOASYL 
Interface, By pursuing this goal, we also eliminate the 
need for changes In the f^BDS and the ABDL, Thus, It Is 
recommended that the Implementation of the COOASYL Interface 
follow closely, the Implementations of the DL/I and SOL 
Interfaces, The Implementor (s) should pay particular 
attention to any commonalities between funtlons and data 
structures , 

we feel that the work presented herein Is sufficient for 
Implementation of the COOASYL Interface, All that remains 
Is for the code to be written, and placed In the host 
computer. Once the COOASYL Interface and the Oaplex 
Interface nave been completely Implemented, the system 
should be tested as a complete system for projected 
efficiency, effectiveness, and responsiveness to user needs. 
It Is anticipated that this research and development effort 
will ultimately result In a new era for database management 
that will allow for Increased productivity and profitability 
In the marketplace. 
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APPENDIX - THE KMS PROGRAM SPECIFIC A TIONS 



Currency Indicator Table 

References made in the following specification to CIT refer to the Currency Indicator Table. 
This table consists of structures that hold information identifying the current record of record- 
type, set-type, and run-unit (run-unit is the application program being run). The following is the 
proposed structure for this table [Ref. 13|. 
struct CIT 

{ 



} 



struct RUN-UNIT 
struct rec-type-node 
struct set-type-node 



run; 

*next-rec-type; 

*next-set-type; 



struct RUN-UNIT 

{ 

char rec-type[ ]; 
int dbkey; 

} 

For each record type in schema: 
struct rec-type-node 
{ 

char type[ |; 

int dbkey; 

struct rec-type-node *next-rec-type; 

} 



For each set type in schema: 
struct set-type-node 

{ 

boolean OWNER; 

char TYPE[ 1; 

int dbkey; 

char memberj ); 

char owner[ ]; 

int owner-dbkey; 

struct set-type-node *next-set-type; 
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%{ 



boolean: first-move — TRUE /* flag for MOVE operation */ 
boolean: first-time /* general purpose flag */ 
boolean: sys-flag-value /* boolean value of system flags * / 
ptr: curr-temp-rec /* ptr to last record added to move-list * / 
ptr: curr-temp-item /* ptr to next item node to be added to 

record-template node of movelist */ 
list: suppression-list /* list of record types and/or set types */ 

for which currency updates are suppressed * / 
/* list of data items used for record section * j 
/* list of sets to which current of run 
unit is to be connected or disconnected */ 

/* list of attribute names to be accessed * j 
f* list of record templates used with 
MOVE statement */ 

curr-non-dup-list /* list of data items for which duplicates 
are not allowed in current record-type */ 
j* level of data item in record types * / 

/* string variable to hold a name */ 



list: select-list 
list: connect-list 

list: tgt-list 
list: move-list 



list: 



int: level-number 
char; member-type 



%) 
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start statement 



statement: ddl-statement 
I dml 



dml: dml-statement 
I dml dml-statement 



ddl-statement: schema-defn record-list set-list 

f 



schema-defn: SCHEMA NAME IS schema-name SEMI-COLON 

{ 

locate db-id schema header node 
if (db names do not match) 
print (’’Error-given db-name doesn’t 
match name in file”) 
perform yyerror() 
return 
end-if 

initialize db-key /* starting value is 1 */ 

} 

record-list: record-desc 

{ 

set db-id node ndn-first-rec ptr 

} 

I record-list record-desc 
{ 

connect successive record nodes 

} 

) 

record-desc: record data-item-list 

{ 

curr-non-dup-list = NULL 

} 



record: RECORD NAME IS 

{ 

allocate and init a new 
record node (NREC-NODE) 
allocate curr-non-dup-list 
db-id-node ndn-num-rec-f-t- 
} 

record-spec 
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record-spec: record-type 

{ 

if (record-type not defined yet) 
copy record-type to current 
record node (NREC-NODE) 
make this the current record node 
end-if 
else 

print (**Error-Vecord-type’ record 
doubly defined”) 
perform yyerror() 
return 
end-else 

} 

SEMI-COLON duplicates-list 



set-list: empty 
I set-desc 
{ 

set db-id node ndn-first-set ptr 

} 

! set-list set-desc 

{ 

connect successive set node(s) 

} 



set-desc: set-desig owner-spec member-spec 
) 



set-desig: SET NAME IS 

{ 

allocate and init a new set node (NSET-NODE) 
db-id-node ndn-num-set-|--t- 
} 

set-type 

{ 

if (set-type not yet defined) 
copy set-type to current set node (nsn-name) 
establish curr-set-ptr 
end-if 
else 

print ("Error-’set-type’ set doubly defined in db") 
perform yyerror() 
end-else 

} 

SEMI-COLON 



97 



owner-spec: OWNER IS aa SEMI-COLON 



j 



aa: record-type 

if (record-type not defined) 
print (*’Error-’record-type’ record does not exist") 
perform yyerror() 
return 
end-if 
else 

copy record-type to current set node (nsn-owner-name) 
locate record-type node 
nsn-owner(ptr) = record-type node 
end-else 
} 

I SYSTEM 



member-spec: MEMBER IS record-type 

{ 

if (record-type not defined) 
print ("Error-’record-type’ record does not exist") 
perform yyerror() 
return 
end-if 
else 

copy record-type to current set node (nsn-member-name) 
locate record-type node 
nsn-member(ptr) = record-type node 
end-else 

} 

SEMI-COLON insert-clause retention-clause 

{ 

alloc set-select node 

} 

set-select-clause SEMI-COLON 



duplicates-list: empty 

I dupl SEMI-COLON 



dupl; duplicate-spec 
I dupl duplicate-spec 

5 



duplicate-spec: DUPLICATES ARE NOT ALLOWED FOR item-spec 
> 
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item-spec: item-name 

{ 

alloc new non-dup node 

copy item-name to non-dup node 

add non-dup node to curr-non-dup-list 

. } 

I item-spec COMMA item-name 

{ 

alloc successive non-dup nodes 
copy successive item-names to non-dup nodes 
add successive non-dup nodes to curr-non-dup-list 
} 



data-item-list: item-desc 



{ 

connect new attr-node to record-node 



} 



I data-item-list item-desc 



{ 

connect successive attr-node(s) to record-node 

} 






item-desc: level-num 

{ 

allocate and init a new attr-node (NATTR-NODE) 
NATTR-NODE nan-level-num = level-number 
record-node nrn-num-attr-f + 

} 

data-item-desc 

{ 

if (nan-level-num = level number of current attribute node) 
connect new attr node to current attr node 
if (nan-level-number > 1) 
connect nan-parent ptr of new node 
end-if 
end-if 

else if (nan-level-number > level number of current attr node) 
connect nan-child ptr of current attr node to new attr node 
connect nan-paxent ptr of new attr node to current attr node 
end-else-if 
else 

locate last attr node with same level number 
set that node’s nan-next-attr ptr to the new attr node 
update current attr pointer 
end-else 

} 
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data-item-desc: item-name 

{ 

copy item-name to attr-node (NATTR-NODE) 
if (item-name not on curr-non-dup-list) 
attr-node nan-dup-flag ~ 1 
end-if 



} 

SEMI-COLON data-type PERIOD 






level-num: empty 

{ 

level-number =1 /* default value */ 

} 

I INTEGER 

{ 

level-number = INTEGER 

} 



data-type: CHARACTER INTEGER 

{ 

attr-node nan-lengthl = INTEGER 
attr-node nan-length2 = 0 
attr-node nan-type = ’c’ 

} 

I FIXED INTEGER 

{ 

attr-node nan-lengthl = INTEGER 
attr-node nan-length2 = 0 
attr-node nan-type = ’i’ 

} 

I FIXED INTEGER 

{ 

attr-node nan-lengthl = INTEGER 

} 

INTEGER 

{ 

attr-node nan-length2 = INTEGER 
attr-node nan-type = T 

} 



100 



insert-clause: INSERTION IS AUTOMATIC 

{ 

set-node nsn-insert = ’a’ 

} 

I INSERTION IS MANUAL 

{ 

set-node nsn-insert = ’m’ 

} 



retention-clause: RETENTION IS FIXED 

{ 

set-node nsn-retent = T 

} 

I RETENTION IS MANDATORY 

{ 

set-node nsn-retent = ’m’ 

} 

I RETENTION IS OPTIONAL 
{ 

set-node nsn-retent = ’o’ 

} 



set-select-clause: empty 

{ 

set-node nsn-select = ’o’ 

} 

1 SEMI-COLON SET SELECTION IS BY set-select-spec 
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set-select-spec: VALUE OF item-name IN record-type 

! 

if(valid-attr(item-name,record-type)) 
copy ’v’ to set-select node select-mode 
copy item-name to set-select node item-name 
copy record-type to set-select node record 1 
copy BLANK to set-select node record2 
end-if 
else 

print(”Error- ’item-name’ not valid for ’record-type”’) 
perform yyerror() 
return 
end-else 

} 

I STRUCTURAL item-name IN record-type 

{ 

if (valid-attr (item-name, record- type)) 
copy ’s’ to set-select node select-mode 
copy item-name to set-select node item-name 
copy record-type to set-select node recordl 
end-if 
else 

print(”Error-’item-name’ not valid for ’record-type’”) 

perform yyerror() 

return 

} 

EQ item-name IN record-type 

if(previous item-name equals this item-name) 
if (valid-attr(item-name, record-type)) 
copy record-type to set-select node record2 
end-if 
else 

print(”Error- ’item-name’ is not valid for ’record-type’”) 
perform yyerror() 
return 
end-if 
else 

print(”Error-’item-name’ items do not match”) 
perform yyerror() 
return 
end-else 
} 

I APPLICATION 

{ 

copy ’a’ to set-select node select-mode 
copy BLANK to recordl, record2, item-name 

} 
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dml-statement: set-flag 
I move 

I get 

I find 
I store 
I connect 
I disconnect 
I erase 
I modify 

I perform-loop /* not designed */ 
I if-then /* not designed */ 



set-flag: MOVE f-value TO f-name 

) 



f-value: YES 

{ 

sys-flag-value = TRUE 

} 

I NO 

{ 

sys-flag-value = FALSE 

} 



f-name: EOF 

{ 

eof = sys-flag-value 

} 

I NOTFOUND 

{ 

notfound = sys-flag-value 

} 
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/* The MOVE statement is a COBOL assignment statement that assigns a */ 
/* value to a particular data Held in a record template. We use a */ 

/* list structure for this purpose. */ 

move: MOVE item-value 

{ 

if (first-move = TRUE) 
alloc and init move-list 
first-move = FALSE 
end-if 

create new data-item-node 

copy ’item-value’ to value field in data-item-node 
establish curr-temp-item pointer 

} 

TO item-name 

copy ’item-name’ to name field in data-item-node 

} 

IN record-type 

if (item-name not in record-type for current schema) 
perform error(2) 
return 
end-if 

else if (’record-type’ node on move-list) 

connect curr-temp-item to record-template node 
end-else-if 
else 

create new record-template node 

copy ’record-type’ to name field of record-template node 
connect curr-temp-item to record-template node 
add record-template node to move-list 
update curr-temp-rec pointer 
end-else 

/* The GET statement takes the entire current record of the run unit */ 

/* or specified data fields of the current record of the run unit */ 

/* and returns the values to the user. */ 

get: GET 

{ 

alloc and init new ’get’ node 
select-list = NULL j* reset select-list */ 

} 

mm 

> 
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mm: item-list IN record-type 

{ 

Lf (^record-type’ is not equal to CIT. RUN-UNIT. type) 
perform error (3) 
return 
end-if 
else 

get-type = ITEMS in get node 
copy record-type to get node 
for (each data-item on item-list) 
if (’data-item’ is not defined for record-type) 
perform error(2) 
return 
end-if 

else /* create pseudo tgt-list * j 
copy data-item to get node 
end-else 
end-for 
end-else 
} 

I record-type 

{ 

if (’record-type’ is not equal to CIT. RUN-UNIT. type) 
perform error(3) 
return 
end-if 
else 

get-type = RETURN-ALL in get node 
copy ’record- type’ to get node 
end-else 

} 

I empty 

{ 

get-type = RETURN-ALL in get node 
copy ClT.RUN-UNIT.type to get node 
} 



/* The FIND statements establish the current of run unit, record type, */ 
/* and set type. * J 

find: FIND record-selection-expr curr-suppression 
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/* The FIND ANY means: find any record of type record-type v^hose */ 

/* values for iteml through itemn match those in that record’s */ 

/* template in the user work area. */ 

record-selection-ex pr: ANY record-type 

{ 

if (’record-type’ record-template node is not 
on move-list) 
perform error(l) 
return 
else 

alloc and init new ’find’ node 
find-type = ANY in find node 
copy record-type to find node 
alloc and init new abdl-str 
alloc and init new tgt-list 
/* begin forming a RETRIEVE request */ 
copy RETRIEVE ((TEMPLATE = ’record-type’)** 
to abdl-str 
end-if 

select-list = NULL 

} 

USING ilem-Iist IN record-type 

{ 

if (’record-type’ is same as previous ’record-type’) 
if (any data item on select-list is not 
defined for record-type) 
perform error(2) 
return 
end-if 
else 

create tgt-list item for all attributes 
of ’record-type’ record 
for (each data item on select-list) 
if (’data-item’ not on move-list) 
perform error (l) 
return 
end-if 
else 

get ’item-value’ from move-list 
concat **and (’data-item’ = ’item-value’)** 
to abdl-str 
end-else 
end-for 

concat **) (’tgt-list ’) by DBKEY]** to abdl-str 
connect abdl-str to find node 
end-else 
end-if 
else 

perform error(6) 
return 
end-else 

} 
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/* The FIND CURRENT means: Make the current of set-type the current */ 
/* record of the run unit. */ 

I CURRENT record-type WITHIN set-type 
{ 

if (CIT. set-type. TYPE is not equal to ’record-type’) 
perform error (7) 
return 
end-if 
else 

/* current of run-unit becomes current of ’set-type’ */ 
alloc and init new ’find’ node 
find-type = CURRENT in find node 
copy record-type to find node 
copy set-type to find node 
copy CIT. set-type. dbkey to find node 
end-else 
} 

/* The FIND DUPLICATE means: Find the first record in the current set- */ 
/* type occurrence whose value for iteml through itemn matches those */ 

/* for the same items in the current set-type occurrence, not the UWA */ 

/* record template. This implementation assumes the records being re- */ 

/* quested are already in a buffer. */ 

I DUPLICATE WITHIN set-type 

{ 

alloc and init new ’find’ node 
find-type = DUPLICATE in find node 
copy set-type to find node 
select-list = NULL /* reset select-list */ 

} 

USING item-list IN record-type 

{ 

if ((record-type is not CIT. set-type. TYPE) or 
(record-type is not CIT. set-type. member)) 
perform error(8) 
return 
end-if 
else 

copy record-type to find node 
for (each data-item on select-list) 
if (any data-item on select-list is not 
defined for record-type) 
perform error(2) 
return 
end-if 

else /* create a pseudo tgt-list */ 
copy data-item to find node 
end-else 
end-for 
end-else 

} 
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/* This statement means: Find the FIRST, LAST, NEXT, or PRIOR record- j 
/* type record within the current set-type occurrence. The 11 token */ 

/* takes the value FIRST, LAST, NEXT, or PRIOR. */ 

1 II record-type WITHIN set-type 

{ 

if ( Vecord-type^ is not a valid member type 
for ’set-type’) 
perform error(5) 
return 
end-if 
else 

copy record-type to find node 
copy set-type to find node 

/* RETRIEVE all member records of set occurrence */ 

alloc and init new abdl-str 
alloc and init new tgt-list 
copy ’‘[RETRIEVE ( 

(TEMPLATE = CIT. set-type. member) and 
(MEMBER. set-type = CIT. set-type. owner-dbkey))” 
to abdl-str 

create tgt-list for all attributes of member record 
concat ”(’tgt-list’) by DBKEY]” to abdl-str 
connect abdl-str to find node 
end-else 

} 

/* The FIND OWNER means; Find the owner of the current set-type occurrence * f 

\ OWNER WITHIN set-type 

{ 

alloc and init ’find’ node 
find-type = OWNER in find node 
copy set-type to find node 
alloc and init new abdl-str 
alloc and init new tgt-list 

/* form RETRIEVE request */ 

copy "[RETRIEVE ((TEMPLATE = CIT.set-type.owner) 
and (DBKEY = ClT.set-type. owner-dbkey))" 
to abdl-str 

create tgt-list for all attributes of owner record 
concat "(’tgt-list’)j" to abdl-str 
connect abdl-str to find node 

} 
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/* This statement means: Find the first record-type record within the */ 

/* current set-type occurrence whose values for iteml through itemn */ 

/* match the values found in the record-type template in the UWA, not */ 
/* the values in the current of set-type as in the FIND DUPLICATE. */ 

I record-type WITHIN set-type CURRENT 

{ 

if (’record-type’ not a member type of ’set-type’) 
perform error(5) 
return 
end-if 
else 

alloc and init new Tind’ node 
find-type = WITHIN in find-node 
copy record-type to find node 
copy set-type to find node 
alloc and init new abdl-str 
alloc and init new tgt-list 

/* begin forming RETRIEVE request */ 

copy "iRETRIEVE ((TEMPLATE = ’record-type’) and 
(MEMBER. set-type = CIT. set-type. owner-dbkey)** 
to abdl-str 

create tgt-list for all attributes of ’record-type’ 
record 

select-list = NULL /* reset select-list */ 
end-else 

} 

USING item-list IN record-type 

if (any data-item on select-list is not defined 
for ’record-type’) 
perform error(2) 
return 
end-if 

else if (any data-item on select-list 
not on move-list) 
perform error (1) 
return 
end-else- if 
else 

for (each data-item on select-list) 
get ’item-value’ from move-list 
concat "and (’data-item’ = ’item-value’) 
to abdl-str 
end-for 

concat ")(’tgt-list’) by DBKEY]" to abdl-str 
connect abdl-str to find node 
end-else 
} 
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11: FIRST 

{ 

alloc and init new ’find’ node 
find-type = FIRST in find node 
} 

LAST 

{ 

alloc and init new Tind’ node 
find-type = LAST in find node 

} 

NEXT 

{ 

alloc and init new Tind’ node 
find-type = NEXT in find node 

} 

PRIOR 

{ 

alloc and init new ’find’ node 
find-type = PRIOR in find node 

} 



curr-suppression: LSQUARE supp-expr RSQUARE 
I empty 



supp-expr; SUPPRESS UPDATE 
I UPDATE type-spec 



type-spec: set-type 

{ 

add set-type to suppression-list 

} 

I type-spec COMMA set-type 

add successive set-types to suppression-list 

} 
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/* This statement means: Delete the current record of the run unit, */ 

/* and all of its descendents regardless of whether they are owners of "*/ 

/* other sets. */ 

erase: ERASE ALL record-type 

{ 

if (’record-type’ is not CIT. RUN-UNIT. type) 
perform error (3) 
return 
end-if 
else 

alloc and init new ’erase’ node 
erase-type = ALL in erase node 
for (each set-type in schema) 
if (CIT. set-type. owner-dbkey = CIT.RUN-UNIT.dbkey) 
member-type = CIT. set-type. member 

/* form RETRIEVE to get member records * j 
alloc and init new abdl-str 

copy"[RETRIEVE(MEMBER.set-type = CIT.RUN-UNIT.dbkey) 
(DBKEY) by DBKEY]" to abdl-str 
connect abdl-str to erase node 

j* erase member records */ 
alloc and init new abdl-str 

copy" [DELETE( (TEMPLATE = ’member-type’) and 
(DBKEY =***))]" to abdl-str 
connect abdl-str to erase node 

/* delete all descendants of member records */ 
perform erase-all(member-type, erase node) 
end-if 
end-for 

/* delete current of RUN-UNIT */ 
alloc and init new abdl-str 

copy "[DELETE((TEMPLATE= ’record-type’) and 
(DBKEY = CIT.RUN-UNIT.dbkey))]" to abdl-str 
connect abdl-str to erase node 
end-else 

} 
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/* This statement means: Delete the current record of the run unit if */ 
/* and only if, it is not the owner of a non-empty set. */ 

I ERASE record-type 
{ 

if (’record-type’ is not CIT. RUN-UNIT. type) 
perform error(3) 
return 
end-if 
else 

/* erase one record - current of RUN-UNIT ^ j 
alloc and init new ’erase’ node 
erase-type = NULL in erase node 

/ * form RETRIEVE to see if ’record-type’ is */ 

/* owner of non-empty set */ 

alloc and init new abdl-str 
copy ”;RETREIVE(” to abdl-str 
first-time = TRUE 
for (each set-type in schema) 
if (’record-type’ is owner type of set-type) 
if (first-time) 

concat ^(MEMBER. set-type = CIT. RUN-UNIT. dbkey)” 
to abdl-str 
first-time — FALSE 
end-if 
else 

concat **or (MEMBER. set-type = CIT. RUN-UNIT. dbkey)” 
to abdl-str 
end-else 
end-if 
end-for 

concat *’)(DBKEY) by DBKEYj” to abdl-str 
connect abdl-str to erase node 

/* for DELETE request */ 
alloc and init new abdl-str 

copy ^[DELETE ((TEMPLATE = CIT.RUN-UNIT.type) and 
(DBKEY = CIT.RUN-UNIT.dbkey))]" to abdl-str 
connect abdl-str to erase node 
end-else 

} 
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/* The STORE means; Create a new record in the database using values */ 

/* supplied by the user via MOVE statements, for the data items of */ 

/* the specified record-type. The is connected to all sets in which */ 

/* INSERTION IS AUTOMATIC. The appropriate occurrence of the sets */ 

/* must be selected before the new record can be connected. This is */ 

I* done based on the SET SELECTION clause specified in the database */ 

/* schema definition for the sets in question. */ 

store: STORE record- type 

{ 

if (’record-ype’ record template node is not on move-list) 
perform error(l) 
return 
end-if 

alloc and init new ’store’ node 
alloc and init new abdl-str 
copy ''[RETRIEVE (" to abdl-str 
first-time = TRUE 

for (each data-item in schema for ’record-type’) 
if (nan-dup-flag is set) 

if (data-item in move-list ’record-type’ record template) 
get data-item value from move-list 
if (first-time = TRUE) 
concat"( (TEMPLATE = ’record-type’) and 

(’data-item’ = ’item-value’))" to abdl-str 
first-time = FALSE 
end-if 
else 

concat "or ((TEMPLATE = ’record-type’) and 

(’data-item’ = ’item-value’))" to abdl-str 

end-else 

end-if 

end-if 

end-for 

concat") (DBKEY) by DBKEY]" to abdl-str 
connect retrieve request to store node 
alloc and init new abdl-str 

/* Form an INSERT request */ 

copy"[INSERT (<TEMPLATE,’record-type’>,<DBKEY,***>" to abdl-str 
for (each ’data-item’ in schema for ’record-type’) 
if (’data-item’ not on move-list for ’record-type’) 
perform error(4) 
return 
end-if 
else 

get data-item value from move-list 
concat", <’item-name’,’item-value’>" to abdl-str 
end-else 
end-for 



113 



/* Now determine which set occurrences the new record belongs to */ 

/* and add proper attribute- value pairs to the INSERT abdl-str to */ 

/* indicate set membership. The following FOR loop and CASE state-*/ 
/* ment fill the INSERT abdl-str with the proper pairs. */ 

for (each set-type in schema in which ’record-type’ is a member) 
case (set selection mode) of 

/* set selection is by applicaton */ 
a: perform by-application(INSERT abdl-str) 

/* set selection is by value */ 
v: perform by-value(INSERT abdl-str) 

/* set selection is by structural */ 
s: perform by-structural(INSERT abdl-str) 

/* no set selection criteria was given */ 
o: perform by-default(lNSERT abdl-str) 

end-case 

end-for 

concat to INSERT abdl-str 
connect INSERT abdl-str to store node 
alloc and init suppression-list 

} 

curr-suppression 

{ 

connect suppression-list to store node 

} 
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/* The MODIFY means: Modify the entire current record of the run unit */ 
/* or the specified data items in that record. The new values are * j 
/* supplied by the user via the UWA. */ 

modify: MODIFY 

{ 

select-list = NULL /* reset select-list */ 

} 

item-list IN record-type 

{ 

if (’record- type’ is not current of run unit) 
perform err or (3) 
return 
end-if 

if (’record- type’ record-template node is not on move-list) 
perform err or (1) 
return 
end-if 

if (any data item on select-list not defined for ’record-type’) 
perform error(2) 
return 
end-if 
else 

alloc and init new ’modify’ node 

locate record-template node on move-list for ’record-type’ 
for (each data-item on select-list) 
alloc and init new abdl-str 
/* form UPDATE request */ 

copy ”[ UPDATE ((TEMPLATE = ’record-type’) and 
(DBKEY = CIT.RUN-UNIT.dbkey))’* to abdl-str 
get ’item-value’ from move-list 
concat *'(’data-item’ = ’item-value’)]” to abdl-str 
connect abdl-str to ’modify’ node 
end-for 
end-else 

} 
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I MODIFY record-type 

{ 

select-list = NULL /* reset select-list */ 
if (’record-type’ not current of run unit) 
perform error(3) 
return 
end-if 

if (’record-type’ record-template node is not on move-list) 
perform error(l) 
return 
end-if 
else 

alloc and init new ’modify’ node 
for (each data-item in record-type) 
if (data-item not on move-list for ’record-type’) 
perform yyerror(4) 
return 
end-if 
else 

alloc and init new abdl-str 
/* form an UPDATE request */ 

copy UPDATE ((TEMPLATE = ’record-type’) and 
(DBKEY = CIT.RUN-UNIT.dbkey)) to abdl-str 
get new ’item-value’ from move-list 
concat ”(’data-item’ = ’item-value’)]" to abdl-str 
connect abdl-str to ’modify’ node 
end-else 
end-for 
end-else 

} 
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/* The CONNECT means: Connect the current record of the run unit to the */ 
/* current occurrence of the specified set type. There may be several */ 

/* sets listed in the statement. */ 

connect: CONNECT record-type TO 

if (’record-type’ is not current of run unit) 
perform error(3) 
return 
end-if 
else 

alloc and init connect-list 
end-else 
} 

set-type-list 

{ 

alloc and init ’connect’ node 
for (each ’set-type’ on connect-list) 
if (’record-type’ is not a member type record for ’set- type’) 
or (INSERTION is not manual) 
perform error(5) 
return 
end-if 
else 

alloc and init new abdl-str 

copy [UPDATE ((TEMPLATE = ’record- type’) and 
(DBKEY = CIT.RUN-UNIT.dbkey)) 

(MEMBER. set-type = CIT. set-type. owner-dbkey)]** 
to abdl-str 

connect new abdl-str to ’connect’ node 
end-else 
end-for 

connect-list = NULL /* reset connect-list */ 

} 



set-type-list: set-type 

{ 

add ’set-type’ to connect-list 

} 

I set-type-list COMMA set-type 

{ 

add successive ’set-type’(s) to connect-list 

} 
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/* The DISCONNECT means: Disconnect the current record of the run unit ^ / 
/* from the set type occurrence that contains the record. ^ J 

disconnect: DISCONNECT record-type FROM 

{ 

if (’record-type’ record is not current record of run unit) 
perform error(3) 
return 
end-if 
else 

alloc and init new connect-list 
end-else 
} 

set-type-list 

alloc and init ’disconnect’ node 
for (each set-type on connect-list) 
if (’record-type’ is not a member type record for ’set-type’) 
perform error(5) 
return 
end-if 
else 

alloc and init new abdl-str 

copy "[UPDATE ((TEMPLATE = ’record-type’) and 
(DBKEY = CIT.RUN-UNIT.dbkey)) 

(MEMBER.set-type = NULL)]" 
to abdl-str 

connect abdl-str to ’disconnect’ node 
end-else 
end-for 

connect-list = NULL /* reset connect-list */ 

} 



perform-loop: PERFORM UNTIL bb EQ cc 
I END-PERFORM 



bb. EOF 
I NOTFOUND 



cc: YES 
I NO 
) 
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item-list; item-name 

{ 

put item-name on select-list 

} 

I item-list COMMA item-name 

{ 

put successive item names on select-list 

} 



schema-name: IDENTIFIER 



record-type; IDENTIFIER 



set-type: IDENTIFIER 



item-name; IDENTIFIER 



item-value: IDENTIFIER 
I INTEGER 
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proc error(err-code) 

/* This procedure prints error messages, causes data structures to */ 
/* be de-allocated, and causes proc yyerror to be executed. */ 



case err-code of 

1: print(**Error - must initialize ’record-type’ record-template”) 

2: print(”Error - ’data-item’ not defined in ’record-type’”) 

3: print(”Error - ’record-type’ is not current record of run unit”) 

4: print(”Error - attempting to modify or store record without 
giving value of ’data-item’”) 



5: print(”Error - ’record-type’ record does not belong to ’set-type’”) 

6: print(”Error - record-types specified are not the same”) 

7; print(”Error - ’record-type’ is not current of ’set-type’”) 

8: print(”Error - ’record-type’ must be a member record of ’set-type’”) 
end-case 

perform cleanup() /* free data structures */ 
perform yyerror() 
return 
end-error; 
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proc by-application(abdl-str) 

if (set-node nsn-insert =’a’ ) /* insertion mode is automatic * / 
concat”, <MEMBER. set-type, CIT. set-type. owner-dbkey>” to abdl-str 
end-if 

else /* insertion mode is manual */ 
concat”,<MEMBER. set-type, NULL>” to INSERT abdl-str 
end-else 

end-by-application; 



proc by-value( abdl-str) 

locate data-item node in schema for set-select node item-name 
in set-select node recordl 
if (nan-dup-flag set) 

get owner record type of set-type from schema 
if (owner record type node not on move-list) or 
(data-item not on move-list) 
perform error(4) 
return 
end-if 
else 

if (set node nsn-insert = ’a’) j* automatic insertion */ 
get data-item value from move-list 

copy”(RETRIEVE((TEMPLATE = owner-record-type) and 
(item-name = ’item-value’)) (DBKEY)]** to abdl-str 
connect new retrieve request to store node 
concat",<MEMBER.set-type,***>" to INSERT abdl-str 
end-if 

else /* manual insertion */ 

concat",<MEMBER. set-type, NULL>” to INSERT abdl-str 
end-else 
end-else 

end-if /* nan-dup-flag */ 
end-by-value; 



121 



proc by-structural(abdl-str) 



locate data-item nose in schema for set-select node item-name 
in set-select node recordl record-type 
if (nan-dup-flag set) 

get recordl name from set-select node for set-type 
if (’recordl’ record template node not on move-list) or 
(data-item not on move-list) 
perform error(4) 
return 
end-if 
else 

if (set-node nsn-insert = ’a’) /* automatic insertion */ 
get data-item value from move-list 
get record2 name from set-select node for set-type 
copy'*[RETRIEVE ((TEMPLATE = record2 name) and 
(item-name = item-value)) (DBKEY)” to abdl-str 
connect new retrieve request to store node 
concat**,<MEMBER. set-type, ***>" to INSERT abdl-str 
end-if 

else I* manual insertion */ 

concat", <MEMBER. set-type, NULL>** to INSERT abdl-str 
end-else 
end-else 

end-if /* nan-dup-flag */ 
end-by-structural; 



proc by-default(abdl-str) 

print('^VVarning - Attempting to store a record with no 
particular set selection given. Will assume ’BY 
APPLICATION’”) 

if (set-node nsn-insert = ’a’) /* automatic insertion */ 
concat”,<MEMBER.set-type,CIT.set-type.owner-dbkey> ” 
to INSERT abdl-str 
end-if 

else /* manual insertion */ 

concat ”,<MEMBER. set-type, NULL>” to INSERT abdl-str 
end-else 

end-by-default; 
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proc erase- all(record-type, erase node) 

string member-type; 

for (each set-type in schema) 
if (’record-type^ is owner type of set-type) 
member-type — member type of set-type 
/* for RETRIEVE to get members of ’set-type’ */ 
alloc and init new abdl-str 

copy '*{RETRIEVE(MEMBER.set-type = ***)(DBKEY) by DBKEYj” 
to abdl-str 

connect abdl-str to erase node 
/* delete member records * / 
alloc and init new abdl-str 

copy ^*|DELETE((TEMPLATE = ’member-type’) and (DBKEY = ***))]»' 
to abdl-str 

connect abdl-str to erase node 
/* erase descendants of member records */ 
erase-all(member-type, erase node) 
end-if 
end-for 

return (erase node) 
end-erase-all 
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